NORTH  ATLANTIC  TREATY 
ORGANISATION 


AC/323(MSG-058)TP/404 


RESEARCH  AND  TECHNOLOGY 
ORGANISATION 


ORGANIZATION 


www.rto.nato.int 


RTO  TECHNICAL  REPORT 


TR-MSG-058 


Conceptual  Modeling  (CM)  for  Military 
Modeling  and  Simulation  (M&S) 

(Model isation  conceptuelle  (MC)  pour  la 
modelisation  et  la  simulation 
(M&S)  militaires) 


Final  Report  of  MSG-058. 


I 


I 


Published  July  2012 


Distribution  and  Availability  on  Back  Cover 


NORTH  ATLANTIC  TREATY 
ORGANISATION 


AC/323(MSG-058)TP/404 


RESEARCH  AND  TECHNOLOGY 
ORGANISATION 


ORGANIZATION 


www.rto.nato.int 


RTO  TECHNICAL  REPORT 


TR-MSG-058 


Conceptual  Modeling  (CM)  for  Military 
Modeling  and  Simulation  (M&S) 

(Model isation  conceptuelle  (MC)  pour  la 
modelisation  et  la  simulation 
(M&S)  militaires) 


Final  Report  of  MSG-058. 


The  Research  and  Technology 
Organisation  (RTO)  of  NATO 


RTO  is  the  single  focus  in  NATO  for  Defence  Research  and  Technology  activities.  Its  mission  is  to  conduct  and  promote 
co-operative  research  and  information  exchange.  The  objective  is  to  support  the  development  and  effective  use  of 
national  defence  research  and  technology  and  to  meet  the  military  needs  of  the  Alliance,  to  maintain  a  technological 
lead,  and  to  provide  advice  to  NATO  and  national  decision  makers.  The  RTO  performs  its  mission  with  the  support  of  an 
extensive  network  of  national  experts.  It  also  ensures  effective  co-ordination  with  other  NATO  bodies  involved  in  R&T 
activities. 


RTO  reports  both  to  the  Military  Committee  of  NATO  and  to  the  Conference  of  National  Armament  Directors. 
It  comprises  a  Research  and  Technology  Board  (RTB)  as  the  highest  level  of  national  representation  and  the  Research 
and  Technology  Agency  (RTA),  a  dedicated  staff  with  its  headquarters  in  Neuilly,  near  Paris,  France.  In  order  to 
facilitate  contacts  with  the  military  users  and  other  NATO  activities,  a  small  part  of  the  RTA  staff  is  located  in  NATO 
Headquarters  in  Brussels.  The  Brussels  staff  also  co-ordinates  RTO’s  co-operation  with  nations  in  Middle  and  Eastern 
Europe,  to  which  RTO  attaches  particular  importance  especially  as  working  together  in  the  field  of  research  is  one  of  the 
more  promising  areas  of  co-operation. 


The  total  spectrum  of  R&T  activities  is  covered  by  the  following  7  bodies: 


•  AVT 

•  HFM 

•  1ST 

•  NMSG 

•  SAS 

•  SCI 

•  SET 


Applied  Vehicle  Technology  Panel 
Human  Factors  and  Medicine  Panel 
Information  Systems  Technology  Panel 
NATO  Modelling  and  Simulation  Group 
System  Analysis  and  Studies  Panel 
Systems  Concepts  and  Integration  Panel 
Sensors  and  Electronics  Technology  Panel 


These  bodies  are  made  up  of  national  representatives  as  well  as  generally  recognised  ‘world  class’  scientists.  They  also 
provide  a  communication  link  to  military  users  and  other  NATO  bodies.  RTO’s  scientific  and  technological  work  is 
carried  out  by  Technical  Teams,  created  for  specific  activities  and  with  a  specific  duration.  Such  Technical  Teams  can 
organise  workshops,  symposia,  field  trials,  lecture  series  and  training  courses.  An  important  function  of  these  Technical 
Teams  is  to  ensure  the  continuity  of  the  expert  networks. 


RTO  builds  upon  earlier  co-operation  in  defence  research  and  technology  as  set-up  under  the  Advisory  Group  for 
Aerospace  Research  and  Development  (AGARD)  and  the  Defence  Research  Group  (DRG).  AGARD  and  the  DRG  share 
common  roots  in  that  they  were  both  established  at  the  initiative  of  Dr  Theodore  von  Karman,  a  leading  aerospace 
scientist,  who  early  on  recognised  the  importance  of  scientific  support  for  the  Allied  Armed  Forces.  RTO  is  capitalising 
on  these  common  roots  in  order  to  provide  the  Alliance  and  the  NATO  nations  with  a  strong  scientific  and  technological 
basis  that  will  guarantee  a  solid  base  for  the  future. 


The  content  of  this  publication  has  been  reproduced 
directly  from  material  supplied  by  RTO  or  the  authors. 
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Conceptual  Modeling  (CM)  for  Military 
Modeling  and  Simulation  (M&S) 

(RTO-TR-MSG-058) 

Executive  Summary 


Purpose 

The  aim  of  this  document  is  to  clarify  the  “Conceptual  Model”  (CM)  concepts;  investigate  methodologies, 
simulation  and  software  engineering  processes;  draft  a  guidance  document  on  CMs  that  can  be  used  by 
different  stakeholders;  foster  the  establishment  of  the  guidance  document  as  a  SISO  standard;  identification 
of  the  relevant  stakeholders  of  CMs;  address  the  needs  of  M&S  community  and  provide  guidance  to 
implementation;  and,  provide  guidelines  for  standards  in  conceptual  modeling  for  M&S. 

Scope  and  Limitations 

The  scope  of  this  guidance  is  nominally  for  NATO  military  M&S.  However,  the  approach  taken  herein  is  to 
provide  comprehensive  guidance  that  can  easily  be  adapted  and  tailored  to  individual  enterprises.  It  can  be 
generalized  to  apply  to  alternative  domains.  NATO  and  national  defense  establishment  M&S  communities- 
of-practice  are  de  facto  enterprises  in  this  spirit  when  the  investment,  development,  maintenance,  and  use  of 
M&S  assets  are  concerned.  While  the  application  of  this  guidance  is  intended  to  be  broad,  its  scope  is 
targeted  to  the  CM  development  process,  and  only  provides  limited  best-practices  pertaining  to  the  rest  of  the 
CM  life  cycle. 

Special  Issues  (Procedures) 

Five  topics  have  been  identified  as  critical.  They  required  special  work  efforts  to  propose  an  appropriate 
solution:  Stakeholder  Analysis  and  Context;  Scope  and  Definition;  Relationship  to  Standards;  Specification 
of  CM  Management  Process;  Specification  of  CM  Artefacts. 

Significant  Considerations,  Analysis/Results 

As  in  Heisenberg  Uncertainty,  where  a  phenomenon  is  disturbed  as  soon  as  one  tries  to  measure  it,  the 
referent  in  a  CM  is  distorted  as  soon  as  one  tries  to  represent  it.  This  is  one  reason  so  many  simulation 
frameworks  have  turned  out  to  be  unusable  or  un-reusable  while  they  were  modeled  as  point  solutions 
such  as  “red  against  blue”,  instead  of  more  composable  structures,  such  as  “entities  and  interactions”. 
The  conceptual  modeling  enterprise  does  not  get  rid  of  these  biases,  as  much  as  it  makes  the  choosing  of 
biases  deliberate  and  well  documented. 

The  CM  of  a  simulation  is  not  simulation  space  implementation  independent.  It  may  appear  to  be  so, 
without  any  specific  references  to  the  simulation  space,  but  the  decisions  that  were  made  during  the  CM 
design  inevitably  were  informed  by  the  underlying  need  for  a  simulation  capability  or  an  enterprise 
interest.  The  value  of  this  guidance  to  enterprises  is  the  provision  of  a  broad  and  flexible  process  with 
defined  products  which  can  be  mapped  against  current  approaches  and  future  plans.  Common  terminology 
can  also  be  derived  from  this  guidance  to  enable  better  communication  of  concepts  between  enterprises. 
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Decisions  and  Recommendations,  Military/NATO  Significance  of  the  Study 

•  NATO  Nations  should  adopt  this  guidance  as  best-practice  for  their  national  and  international  M&S 
efforts  to  enable  interoperability  and  reuse. 

•  The  M&S  community  should  incorporate  CM  development  into  their  M&S  development  processes, 
based  on  the  best-practice  provided  in  this  guidance. 

•  Each  enterprise  should  specify  its  own  conceptual  modeling  process  and  CM  products,  using  this 
guidance  as  a  point  of  reference. 

•  VV&A  of  CMs  should  be  integral  to  the  development  process.  Use  of  the  ISO/IEC  9126  standard 
on  software  quality  is  a  starting  point  for  the  derivation  of  CM  quality  criteria,  and  use  of  the  (draft) 
GM-V&V  standard  is  applicable  to  V&V  of  CMs. 

•  Every  customization  of  the  guidance  should  be  published  to  contribute  to  the  body  of  knowledge  of 
conceptual  modeling,  to  build  a  valuable  experience  base  for  standardization  initiatives. 

•  The  M&S  community  and  the  Simulation  Interoperability  Standards  Organization,  should  use  this 
best-practice  guidance  as  a  basis  to  initiate  an  international  standard  for  CM  development. 
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Moderation  conceptuelle  (MC)  pour  la  modelisation 
et  la  simulation  (M&S)  militaires 

(RTO-TR-MSG-058) 

Synthese 


Objectif 

Le  but  du  present  document  est  de  :  clarifier  les  notions  de  «  modele  conceptuel »  (MC) ;  etudier  les 
methodologies,  les  procedes  de  genie  logiciel  et  de  simulation ;  rediger  une  directive  traitant  des  MC 
pouvant  etre  utilisee  par  differentes  parties  prenantes  ;  agir  en  sorte  que  la  directive  devienne  une  norme 
SISO  (Organisation  de  normalisation  en  vue  de  l’interoperabilite  en  matiere  de  simulation) ;  identifier  les 
bonnes  parties  prenantes  aux  MC  ;  repondre  aux  besoins  du  monde  de  la  modelisation  et  de  la  simulation 
et  lui  fournir  des  directives  de  mise  en  oeuvre  ;  et  foumir  des  lignes  directrices  en  matiere  de  normes  dans 
le  domaine  de  la  modelisation  conceptuelle  destinee  a  la  M&S. 

Portee  et  limitations 

La  presente  directive  porte,  en  principe,  sur  la  M&S  militaire  de  l’OTAN.  Toutefois,  le  parti  retenu  ici  est 
de  fournir  une  directive  complete  pouvant  etre  facilement  adaptee  a  differentes  entreprises.  Elle  peut  etre 
generalisee  pour  s’appliquer  a  d’autres  domaines.  Les  collectivites  qui  assurent  la  mise  en  oeuvre  de  la 
M&S,  qu’elles  se  situent  au  niveau  OTAN  ou  des  etablissements  nationaux  de  defense,  sont  de  facto  des 
entreprises  en  ce  sens  lorsqu’il  s’agit  de  financer,  developper,  entretenir  et  utiliser  les  ressources  en 
matiere  de  M&S.  Bien  que  le  domaine  d’ application  de  la  presente  directive  soit  intentionnellement  vaste, 
sa  portee  est  restreinte  a  la  procedure  de  developpement  de  modele  conceptuel  et  elle  n’indique  que  de 
fagon  limitee  les  meilleures  pratiques  se  rapportant  au  reste  du  cycle  de  vie  dudit  modele  conceptuel. 

Questions  speciales  (Procedures) 

Cinq  domaines  critiques  ont  ete  identifies.  Ils  ont  necessite  une  reflexion  speciale  debouchant  sur  une 
solution  adaptee  :  environnement  et  analyse  de  partie  prenante  ;  portee  et  definition  ;  rapports  avec  les 
normes  ;  specification  de  procedure  de  gestion  de  la  MC  ;  specification  d’artefact  de  MC. 

Considerations  importantes,  analyse/resultats 

De  meme  que,  selon  le  principe  d’incertitude  de  Heisenberg,  on  perturbe  un  phenomene  des  lors  que  Ton 
essaie  de  le  mesurer,  le  referent  dans  une  MC  est  altere  des  que  Ton  essaie  de  le  representer.  C’est  l’une  des 
raisons  pour  lesquelles  tant  de  cadres  de  simulation  se  sont  reveles  etre  inutilisables  ou  non  reutilisables  alors 
qu’ils  etaient  modelises  en  tant  que  solutions  ponctuelles  telles  que  «  rouges  contre  bleus  »,  en  lieu  et  place 
de  structures  plus  accommodantes  telles  qu’«  entites  et  interactions ».  L’entreprise  de  modelisation 
conceptuelle  n’elimine  pas  tant  ces  biais  qu’elle  rend  leur  choix  delibere  et  bien  documents. 

La  MC  d’une  simulation  n’est  pas  independante  de  la  mise  en  oeuvre  de  l’espace  de  simulation.  Cela  peut 
paraitre  etre  le  cas,  sans  aucune  reference  specifique  a  l’espace  de  simulation,  mais  les  decisions  prises 
lors  de  la  conception  de  la  MC  ont  ete  inevitablement  influencees  par  le  besoin  sous-jacent  d’une  capacite 
de  simulation  ou  d’un  interet  d’entreprise.  La  valeur  de  la  presente  directive  pour  les  entreprises  consiste 
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en  la  mise  a  disposition  d’une  procedure  large  et  souple  comprenant  des  produits  definis  qui  peuvent  etre 

organises  en  fonction  des  methodologies  actuelles  et  des  plans  fiiturs.  Une  terminologie  commune  peut 

egalement  etre  tiree  de  la  presente  directive  afin  de  favoriser  l’echange  de  concepts  entre  entreprises. 

Decisions  et  recommandations,  importance  militaire/pour  POTAN  de  P  etude 

•  Les  pays  de  l’OTAN  doivent  adopter  la  presente  directive  en  tant  que  meilleure  pratique  applicable  a 
leurs  efforts  nationaux  et  intemationaux  en  matiere  de  modelisation  et  simulation  (M&S),  et  ce,  en  vue 
de  permettre  l’interoperabilite  et  la  reutilisation. 

•  Le  monde  de  la  M&S  doit  integrer  le  developpement  de  la  modelisation  conceptuelle  (MC)  dans  ses 
processus  de  developpement  de  M&S  en  se  fondant  sur  les  meilleures  pratiques  indiquees  dans  la 
presente  directive. 

•  Chaque  entreprise  doit  indiquer  ses  propres  procedures  de  modelisation  conceptuelle  et  produits  de 
MC  en  utilisant  la  presente  directive  comme  reference. 

•  Les  VV&A  (verification,  validation  et  acceptation)  des  MC  doivent  faire  partie  integrante  du  processus 
de  developpement.  L ’utilisation  de  la  norme  ISO/IEC  9126  sur  la  qualite  des  logiciels  constitue  le  point 
de  depart  d’ou  vont  decouler  les  criteres  de  qualite  de  la  MC,  et  (le  projet  de  norme  ou)  la  norme 
GM-V&V  (methodologie  generique  de  verification  et  validation)  est  applicable  aux  V&V  (verification 
et  validation)  des  MC. 

•  Toute  personnalisation  de  la  directive  doit  etre  publiee  afin  de  contribuer  au  corpus  de  connaissances 
relatives  a  la  modelisation  conceptuelle,  et  ce,  pour  constituer  un  precieux  socle  d’ experience  utile  aux 
initiatives  en  matiere  de  normalisation. 

•  Le  monde  de  la  M&S  ainsi  que  l’Organisation  de  normalisation  en  vue  de  l’interoperabilite  en  matiere 
de  simulation  (SISO)  doivent  utiliser  la  directive  relative  aux  meilleures  pratiques  comme  point  de 
depart  d’une  norme  internationale  en  matiere  de  developpement  de  MC. 
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0.1  PURPOSE 

This  document  is  intended  to  have  the  following  consequential  effects: 

•  Clarify  “Conceptual  Model”  (CM)  concepts,  discuss  the  terminology,  and  emphasize  the  utility  to  better 
formalize  conceptual  models,  understand  the  relationship  between  conceptual  modeling  and  related 
concepts  (scenario  definition,  etc.); 

•  Investigate  methodologies,  simulation  and  software  engineering  processes,  initiatives  and  technologies 
useful  for  the  establishment  and  content  of  conceptual  models; 

•  Draft  a  guidance  document  on  conceptual  models  that  can  be  used  by  different  stakeholders  (sponsor/ 
user,  project  manager,  subject-matter  experts,  V&V  agents,  developers,  etc.); 

•  Foster  the  establishment  of  the  guidance  document  as  a  SISO  standard; 

•  Provide  identification  of  the  relevant  stakeholders  of  conceptual  models  and  considering  whether  a 
prioritization  is  needed; 

•  Address  the  needs  of  M&S  community,  identifying  the  way  conceptual  models  may  contribute  to  M&S 
development,  and  providing  guidance  to  implementation;  and 

•  Provide  guidelines  for  standards  in  conceptual  modeling  for  M&S;  thereby  specifying  a  conceptual 
model  to  be  (re)usable  by  users  with  similar  knowledge  and  to  be  accepted  by  the  computer  science 
community. 

0.2  SCOPE  AND  LIMITATIONS 

The  scope  of  this  guidance  is  nominally  for  NATO  military  M&S.  However,  the  approach  taken  herein  is  to 
provide  comprehensive  guidance  that  can  easily  be  adapted  and  tailored  to  individual  enterprises.  It  can  be 
generalized  to  apply  to  alternative  domains.  NATO  and  national  defence  establishment  M&S  communities-of- 
practice  are  de  facto  enterprises  in  this  spirit  when  the  investment,  development,  maintenance,  and  use  of  M&S 
assets  are  concerned.  While  the  application  of  this  guidance  is  intended  to  be  broad,  its  scope  is  targeted  to  the 
CM  development  process,  and  only  provides  limited  best-practices  pertaining  to  the  rest  of  the  CM  life  cycle. 


0.3  SPECIAL  ISSUES  (PROCEDURES) 

Five  topics  were  identified  as  critical  to  the  TR-MSG-058  Task  Group’s  efforts  that  required  special  attention 
to  achieve  an  appropriate  outcome  to  the  Groups  work-product.  Those  issues  included: 

1)  Sensitivity  to  stakeholder  analysis  and  context; 

2)  Precise  specification  of  study  scope  and  definition  of  terms; 

3)  Explication  of  relationships  of  conceptual  modeling  practice  and  products  to  existing  standards; 

4)  Specification  of  conceptual  model  management  process;  and 

5)  Specification  of  resulting  conceptual  model  documentary  artifacts. 
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0.4  SIGNIFICANT  CONSIDERATIONS,  ANALYSIS/RESULTS 

Two  particular  considerations  assumed  special  prominence  during  the  effort  of  the  Group’s  deliberations. 
In  each  case  the  Group  made  every  effort  to  appreciate  the  underlying  nature  and  logical  entailments  of  these 
considerations  and  to  produce  analyses  and  work-product  results  that  were  reasonably  commensurate  both  the 
implications  of  these  considerations  and  the  need  for  practitioners  to  deal  with  those  implications  in  straight¬ 
forward  pragmatic  ways. 

The  first  consideration  is  the  fact  of  ‘ontological  relativism’  whereby  every  abstraction  of  a  referent  domain 
by  way  of  conceptualization  has  inherent  systematic  biases  that  depend  strongly  on  the  perceptual  frame  of  the 
modeler  and  that  may  so  particularize  a  consequent  conceptual  model  that  alternative  models,  while  drawn 
from  the  same  reality,  are  not  in  fact  ‘complementary’  or  semantically  consistent.  Conceptual  modeling 
process  and  conceptual  model  product  artifacts  recommended  by  the  Study  Group  were  particularly  conceived 
and  phrased  so  as  to  make  this  risk  to  re-use  and  interoperability  of  conceptual  models  and  consequent 
simulations  apparent  and  to  provide  such  guidance  as  could  be  made  prescriptive  whereby  this  risk  might  be 
ameliorated. 

The  second  consideration  of  import  addressed  by  the  Group  was  the  question  of  whether  simulation  conceptual 
models  should  be  in  some  significant  way  simulation-implementation  independent.  By  designating  fully 
simulation  independent  abstractions  of  the  referent  world  as  ‘conceptual  system-reference-models’  rather  than 
conceptual  simulation-models,  the  Group  proceeded  to  include  both  the  objective  system-space  and  the 
simulation-space  in  its  scope.  Consequently,  the  decisions  that  are  recommended  to  be  made  during  the 
conceptual  model  design  inevitably  will  be  informed  by  the  underlying  need  for  a  simulation  capability  or  an 
enterprise  interest.  The  value  of  this  guidance  to  enterprises  is  the  provision  of  a  broad  and  flexible  process  with 
defined  products  which  can  be  mapped  against  current  approaches  and  future  plans.  Common  terminology  can 
also  be  derived  from  this  guidance  to  enable  better  communication  of  concepts  between  enterprises. 


0.5  DECISIONS  AND  RECOMMENDATIONS,  MILITARY/NATO 
SIGNIFICANCE  OF  THE  STUDY 

•  NATO  Nations  should  adopt  this  guidance  as  best-practice  for  their  national  and  international  M&S 
efforts  to  enable  interoperability  and  reuse. 

•  The  M&S  community  should  incorporate  CM  development  into  their  M&S  development  processes,  based 
on  the  best-practice  provided  in  this  guidance. 

•  Each  enterprise  should  specify  its  own  conceptual  modeling  process  and  CM  products,  using  this  guidance  as 
a  point  of  reference. 

•  VV&A  of  CMs  should  be  integral  to  the  development  process.  Use  of  the  ISO/IEC  9126  standard  on 
software  quality  is  a  starting  point  for  the  derivation  of  CM  quality  criteria,  and  use  of  the  (draft)  GM-V&V 
standard  is  applicable  to  V&V  of  CMs. 

•  Every  customization  of  the  guidance  should  be  published  to  contribute  to  the  body  of  knowledge  of 
conceptual  modeling,  to  build  a  valuable  experience  base  for  standardization  initiatives. 

•  The  M&S  community  and  the  Simulation  Interoperability  Standards  Organization,  should  use  this  best- 
practice  guidance  as  a  basis  to  initiate  an  international  standard  for  CM  development. 
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Chapter  1  -  BACKGROUND  OF  MSG-058  EFFORT 

Conceptual  models  are  key  to  the  transformation  of  user  needs  and  requirements  to  modeling  and  simulation 
(M&S)  design,  implementation  and  use.  Conceptual  models  form  the  bridges  of  understanding  between  the 
users  of  M&S,  the  military  domain  experts  that  have  the  necessary  knowledge  that  must  be  represented  in 
M&S,  and  the  software  and  simulation  engineers  that  implement  simulations.  Neither  a  standard  practice  for 
conceptual  model  development  nor  consensus  definition  of  conceptual  model  content  currently  exists.  Where 
conceptual  modeling  is  practiced,  it  is  typically  defined  on  a  project-to-project  basis.  A  recommended  best- 
practice  including  specification  of  the  content  of  conceptual  models  for  M&S  will  increase  user  understanding 
of  the  capabilities  of  those  M&S,  thus  increasing  their  reusability  and  interoperability. 

The  North  Atlantic  Treaty  Organisation  (NATO)  Modeling  and  Simulation  Group  (NMSG)  was  established 
within  the  Research  and  Technology  Organisation  (RTO)  in  1999,  with  an  objective  to  favour  re-use  and 
interoperability  of  M&S  within  the  Alliance,  and  NATO/PfP  Nations.  So  far,  within  NATO,  as  within  the 
international  M&S  community,  the  interoperability  objective  has  been  mainly  addressed  at  the  “technical  level” 
using  open  standards  developed  by  the  Simulation  Interoperability  Standards  Organization  (SISO),  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE)  or  International  Organization  for  Standards  (ISO),  such  as  the  High 
Level  Architecture  (HLA)  that  was  adopted  by  NATO  as  early  as  1998.  Those  standards  have  provided  a  first 
step  to  interoperability  and  a  state-of-the-art  way  to  interconnect  simulations  and  tools  to  build  distributed 
systems  of  simulations;  but  it  is  recognized  that  existing  standards  are  neither  intended  nor  sufficient  for 
specification  and  controlled  exchange  of  semantics  and  concepts. 

Since  the  beginning  of  the  NMSG  activity,  it  was  recognized  that  HLA  was  only  a  preliminary  step  to  satisfy 
the  M&S  technical  interoperability  concern  and  that  the  final  objective  was  still  to  achieve  a  more  ambitious 
M&S  “interoperability  level”.  This  final  objective  should  be  to  achieve  a  common  understanding  and  use  of 
information  exchanged  between  simulations  for  better  satisfying  military  requirements  for  education,  training 
and  operational  support.  Without  conceptual  models,  history  has  shown  that  simulation  developers  often  do 
not  sufficiently  understand  the  military  domain  to  be  modelled,  implement  M&S  that  do  not  reflect  the 
intended  reality,  and  thus  do  not  satisfy  the  user’s  needs.  Further,  conceptual  models  form  the  basis  of  an 
important  step  in  Verification  and  Validation  -  determining  that  the  application  domain  has  been  described 
sufficiently  to  meet  users’  needs  while  accurately  incorporating  Subject-Matter  Expert  (SME)  knowledge. 

SISO  recognized  the  importance  of  better  defining  and  advising  the  M&S  community  on  the  importance  of 
conceptual  models  not  only  for  the  interoperability  issue  but  also  to  form  a  basis  for  simulation  development, 
foster  re-use,  and  to  support  Verification  and  Validation  (V&V)  activities.  A  SISO  Task  Group  was  created  in 
2003  to  address  the  topic  of  conceptual  models  with  the  potential  objective  of  developing  a  new  standard, 
or  more  precisely  a  “guide”,  to  help  practitioners  building  conceptual  models.  While  this  SISO  Task  Group 
did  not  proceed  to  the  publication  of  such  a  guide,  it  nevertheless  produced  interesting  and  valuable  output 
that  can  be  exploited  to  produce  a  recommended  practice  guide  for  the  elaboration  of  conceptual  models. 
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Chapter  2  -  OBJECTIVE  OF  MSG-058  EFFORT 

In  April  2008,  then,  the  NMSG  originated  a  Task  Group  (MSG-058)  to  develop  a  guidance  document  on 
conceptual  models,  which  can  be  used  in  the  future  by  NATO  to  support  its  M&S  requirements.  The  major 
objectives  of  this  Task  Group,  according  to  its  Technical  Advisory  Panel  (TAP)  Terms  Of  Reference  (TOR) 
charter  of  June  2007,  enclosed  as  Annex  A  and  B  respectively  are: 

1)  Clarify  the  “Conceptual  Model”  concepts,  discuss  the  terminology,  and  emphasize  the  utility  to  better 
formalize  conceptual  models,  understand  the  relationship  between  conceptual  modeling  and  related 
concepts  (scenario  definition,  etc.); 

2)  Investigate  methodologies,  simulation  and  software  engineering  processes,  initiatives  and  technologies 
useful  for  the  establishment  and  content  of  conceptual  models; 

3)  Draft  a  guidance  document  on  conceptual  models  that  can  be  used  by  different  stakeholders  (sponsor/ 
user,  project  manager,  subject-matter  experts,  V&V  agents,  developers,  etc.); 

4)  Foster  the  establishment  of  the  guidance  document  as  a  SISO  standard; 

5)  Identify  the  relevant  stakeholders  of  conceptual  models  and  considering  whether  a  prioritization  is 
needed; 

6)  Address  the  needs  of  M&S  community,  identifying  the  way  conceptual  models  may  contribute  to 
M&S  development,  and  providing  guidance  to  implementation;  and 

7)  Provide  guidelines  for  standards  in  conceptual  modeling  for  M&S;  thereby  specifying  a  conceptual 
model  to  be  (re)usable  by  users  with  similar  knowledge  and  to  be  accepted  by  the  computer  science 
community. 

The  Task  Group’s  first  objective  was  to  clarify  what  a  conceptual  model  for  M&S  is  and  what  it  represents. 
A  common  understanding  from  the  outset  of  the  effort  was  that  a  conceptual  model  should  serve  as  a  frame  of 
reference  for  simulation  development  by  documenting  important  entities/concepts,  their  properties,  and  their 
key  actions  and  interactions.  That  is,  a  conceptual  model  should  bridge  between  the  requirements  and  simulation 
design.  The  use  of  simulation  in  military  applications  such  as  training  and  decision  support  requires  that  the 
simulations  are  fit  for  use.  V&V  can  be  applied  to  evaluate  if  this  fitness  for  use  is  achieved.  The  quality  of  the 
end-product  (i.e.,  the  simulator)  is,  however,  largely  dependent  on  the  quality  of  the  intermediate  products. 
To  be  more  specific,  a  large  portion  of  the  problems  with  the  end-product  come  from  a  poor  understanding  of 
the  customer’s  situation  which  leads  to  a  low  quality  of  the  requirements.  Explicitly  building  a  conceptual 
model  is  one  of  the  ways  to  improve  the  quality  of  the  end-product  by  allowing  for  a  good  starting  point  for  its 
development.  In  order  for  the  conceptual  model  to  be  able  to  really  improve  the  quality  of  the  consequent 
simulation,  the  quality  of  the  conceptual  model  itself  must  be  sufficiently  high.  Building  the  conceptual  model 
is  the  step  in  simulation  development  in  which  the  actual  modeling  takes  place.  Therefore  validation  (determining 
whether  the  abstractions  taken  during  the  modeling  are  allowed)  of  the  conceptual  model  against  the 
stakeholders’  purpose  is  important  for  the  simulation’s  fitness  for  purpose.  From  a  project  management  point 
of  view,  the  conceptual  model  is  the  last  step  in  simulation  development  where  correcting  errors,  such  as 
having  erroneously  left  out  important  parts  that  should  be  represented  in  the  end-product,  is  still  relatively 
easy,  quick  and  cheap.  If  design  and  implementation  starts,  correcting  mistakes  quickly  becomes  much  more 
costly.  Therefore  V&V  of  the  conceptual  model  is  an  important  form  of  risk  mitigation. 

Therefore,  the  Task  Group  endeavoured  to  clarify  and  rigorously  define  the  core  terminology  associated  with 
conceptual  models  and  conceptual  modeling,  and  the  relationship  among  those  terms.  Among  the  issues  the  Task 
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Group  addressed  was  clarification  of  key  concepts  in  respect  to  which  are  framed  the  needs  each  of  these 
stakeholders  in  a  conceptual  model  and  the  level  of  abstraction  at  which  conceptual  models  should  be  expressed 
to  meet  various  stakeholders’  needs.  Conceptual  Models  are  one  of  the  key  concepts  in  the  development  and 
employment  lifecycle  of  M&S.  As  such  it  is  related  to  other  concepts  such  as  scenario  development, 
simulation  software  requirements  development,  and  test  plan  development.  As  part  of  the  first  objective, 
the  Task  Group  defined  the  relationships  among  conceptual  models  and  these  other  activities. 

The  second  objective  of  this  Task  Group  was  to  investigate  methodologies,  simulation  engineering  and 
software  engineering  processes,  initiatives  and  technologies  useful  for  the  establishment  and  content  of 
conceptual  models.  While  the  objective  of  this  Task  Group  was  not  to  develop  or  identify  a  single  standard  for 
the  representation  of  conceptual  model  content,  this  Task  Group  did  identify  a  range  of  such  solutions  that  can 
be  employed  in  conceptual  models.  In  order  to  take  advantage  of  the  work  covered  by  others  regarding  to  this 
issue,  it  was  very  important  to  collect  and  analyze  as  much  as  possible  of  the  documentation  available  on 
conceptual  models  -  especially  those  related  to  the  M&S  field.  Lesson  learnt  by  them  helped  to  avoid  some 
recurrent  problems,  to  reduce  the  risk  of  developing  simulation  not  adapted  to  the  requirements  and  to  get  the 
greatest  benefit  from  the  effort  of  this  Task  Group.  The  Task  Group  explored  the  potential  of  a  variety  of 
processes  and  knowledge  representation  approaches  to  examine  their  potential  for  conceptual  modeling. 
Through  this  objective,  the  Task  Group  synthesized  existing  practices  to  identify  the  state-of-the-art  of 
conceptual  modeling.  By  doing  this,  the  Task  Group  maximized  the  reuse  of  previous  effort  in  the  development 
of  a  recommended  practice. 

The  third  objective  of  the  effort  was  to  provide  a  tailorable  set  of  guidance  to  the  M&S  community  on 
conceptual  modeling  processes  and  products.  This  will  guide  users  through  the  conceptual  modeling  effort  by 
explaining  how  to  apply  it  in  practice.  The  process  will  be  tailorable  in  that  it  is  intended  to  be  extended  and 
modified  by  individual  programs  that  apply  it.  Rather  than  being  a  one-size-fits-all  rigid,  single  approach  to 
conceptual  modeling,  the  guidance  will  provide  a  starting  point  that  individual  programs  can  apply  given  their 
specific  needs  and  resources.  The  guidance  on  the  conceptual  model  content  will  state  what  should  be  in  the 
conceptual  model,  and  not  mandate  a  specific  format  but  suggestions  for  the  selection  and  use  of  format, 
methodology,  techniques  and  tools  will  be  provided.  The  guidance  will  encompass  the  conceptual  model 
process,  conceptual  model  content  and  describe  appropriate  views  on  a  conceptual  model  for  different 
stakeholders.  For  example,  the  conceptual  model  process  will  describe  the  transformation  from  the  users  view, 
concerned  with  the  problem  domain,  to  the  developers  view,  focused  on  the  M&S  domain. 

The  Task  Group’s  fourth  objective  was  to  foster  the  establishment  of  the  guidance  document  as  a  SISO 
standard.  The  current  policy  of  NATO  for  standardization  is  to  use  civil  standards  where  appropriate  ones 
exist  and  to  develop  its  own  standards  only  when  no  civil  standard  exists.  In  the  case  of  conceptual  models  for 
M&S  or  conceptual  models  in  general,  no  civil  standard  exists.  The  requirement  for  M&S  conceptual  model  is 
not  specific  to  NATO  or  to  the  military  domain.  Thus  it  should  be  helpful  to  extend  this  work  to  a  larger  M&S 
community.  With  respect  to  this  proposal,  the  Task  Group  broadened  its  guidance  document  to  comprehend  in 
its  work-product  the  scope  of  an  M&S  standard  product,  developed  through  an  open  consensus-based 
standards  body.  The  SISO  is  the  best-suited  organization  for  this  standardization,  since  it  has  a  strong 
background  and  current  focus  on  military  M&S,  but  also  includes  M&S  practitioners  from  outside  the  military 
domain.  Finally,  the  Task  Group  collaborated  with  SISO’s  Standing  Task  Group  on  Conceptual  Modeling 
throughout  the  period  of  performance  of  the  effort  in  order  to  facilitate  to  the  greatest  extent  possible  the 
acceptance  of  the  Task  Group’s  work-product  as  the  basis  of  a  successor  SISO/IEEE  standard. 

In  addressing  the  fifth  objective,  the  Task  Group  identified  the  key  stakeholders  in  conceptual  modeling  and 
their  requirements  with  respect  to  conceptual  models.  Stakeholders  will  include  those  that  are  involved  in  the 
production  of  conceptual  models  and  those  that  rely  on  conceptual  models  to  perform  their  jobs. 
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In  response  to  the  sixth  objective,  the  Task  Group  realized  that  the  value  of  its  eventual  work  product  would 
be  dependent  upon  the  degree  to  which  it  provided  value  to  practicing  modeling  and  simulation  professionals 
and  to  the  stakeholders  involved  in  the  M&S  enterprise  wherein  it  is  employed;  the  Group  was  anxious  to 
appreciate  and  to  make  evident  in,  auditably  traceable  form,  its  perception  of  the  wants  and  needs  of  the 
conceptual  modeling  stakeholder  community,  and  the  specific  attributes  desired  of  its  effort  and  of  the 
resulting  work-product  pursuant  to  that  effort.  To  this  effect,  desiderata  were  compiled  from  a  variety  of 
sources  relating  to  each  of  the  following  categories: 

•  Compliance  -  Degree  of  conformance  of  work-process  and  work-product  to  explicit  and  implicit 
guidance. 

•  Completeness  -  Degree  of  exhaustion  of  effort  and  resulting  product  with  respect  to  the  fundamental 
need  to  support  enterprise  conceptual  modeling  of  military  models  and  simulations. 

•  Correctness  -  Degree  of  appropriateness  of  operational  process  and  conceptual  modeling  guidance 
documentation  in  subject  enterprise  environment  ...  roughly  the  degree  to  which  employment  of  the 
published  best-practice  specification  is  likely  to  result  in  satisfactory  conceptual  modeling  practices 
and  conceptual  model  artefacts,  given  requisite  completeness. 

•  Consistency  -  Degree  to  which  the  efforts  of  the  Task  Group  and  its  resulting  work-product  are 
mutually  coherent  and  based  on  common  precepts  and  assumptions. 

•  Utility  -  Degree  to  which  the  employment  of  the  Task  Group  work-product  is  useful  to  stakeholders 
in  generating,  using  and  maintaining  conceptual  models  in  the  NATO  enterprise  environment. 

In  response  to  the  seventh  objective,  the  Task  Groups  have  to  ensure  that  specific  requirements  (e.g.,  attributes 
of  the  Task  Groups  operating  process  and/or  resulting  product)  were  derived  from  task  guidance,  self-generated 
concept  of  operations  of  the  Task  Group,  and  the  consensus  of  product  structure,  and  content  agreed  upon  by  the 
Task  Group  during  its  deliberations.  These  requirements  are  documented  in  Annex  C.  The  requirements  serve 
both  to: 


•  Indicate  the  sensitivities  of  the  Task  Group  in  executing  its  responsibilities  and  to  provide  persistent 
strategic  and  tactical  guidance  for  execution  of  the  Task  Group  effort;  and 

•  Serve  both  the  Task  Group  itself  and  the  recipients  of  the  Task  Group’s  work-product,  by  providing 
the  means  for  evaluation  of  the  work-product  as  against  necessary  and  sufficient  criteria. 
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Chapter  3  -  MSG-058  PROGRAM  OF  WORK 


The  effort  described  in  this  chapter  constitutes  the  program  of  work  executed  by  the  Task  Group  MSG-058, 
which  resulted  in  the  generation  of  the  Study  work-product,  i.e.,  recommended  best-practice  guidance  for 
conceptual  modeling  for  military  models  and  simulations  and  for  the  structure  and  content  of  the  resulting 
conceptual  model  documentary  artefact. 

3.1  INTRODUCTION 

Significant  diverse  and  intensive  technical  effort  was  required  to  meet  the  Task  Group  objective.  Understanding 
conceptual  models  for  military  simulations  requires  employment  of  a  variety  of  precepts,  technical  concepts, 
and  existing  circumstances.  Generating  best-practice  guidance  for  executing  conceptual  modeling  requires 
appreciation  of  a  wide  variety  of  academic  and  practical  techniques  for  ontology  creation  and  conceptual  model 
specification.  Finally,  the  creation  of  useful  best-practice  guidance  requires  appreciation  of  existing  M&S 
management  practice,  and  the  standards  and  techniques  associated  with  specification  of  both  process  and  product 
in  expected  enterprise  operational  environments. 

Elucidation  of  the  effort  conducted  by  the  group  in  executing  the  subject  study  illustrates  clearly  the  diverse 
technical  basis  for  the  resulting  study  conclusions  and  recommendations.  Description  of  the  activities  of  the  Task 
Group,  indication  of  their  necessity  or  motivational  rationale,  and  description  of  their  intended  consequences  in 
accomplishment  of  the  study  objective,  is  intended  to  provide  detailed  context  for  interpretation  and  appreciation 
of  the  study  results  and  recommendations.  The  effort  actually  executed  by  MSG-058  is  described  explicitly 
herein  for  two  purposes.  First,  such  a  description  is  intended  to  demonstrate  the  practical  means  whereby  the 
Group  met  the  conditions  set  forth  in  the  Study  TAP  and  TOR  introduced  above.  Comparison  of  the  account  that 
follows  and  the  prescriptive  guidance  from  reference  guidance  document  illustrates  that  the  ‘way  of  work’  is  in 
fact  compliant  with  guidance,  complete  with  respect  to  scope  of  the  guidance,  and  consistent  both  internally  and 
with  the  intentions  of  the  guidance  itself.  Secondly,  the  following  description  of  the  programme  of  work  actually 
executed  by  the  Group  should  provide  implicit  evidence  to  the  reader  of  this  report  and  the  agent  striving  to 
follow  the  best-practices  guidance  recommended  herein  regarding  both  the  quality  of  the  effort  and  consequent 
work-product,  and  the  significance  and  relevance  of  the  subject  best-practice  guidance  proffered  below  to  the 
reader/user’s  needs  and  interests. 

The  approach  adopted  by  the  Group  in  addressing  all  these  foundational  matters  was  to  first  identify  particular 

topics  that  seemed  to  entail  issues  of  significance  or  particular  difficulty;  to  address  each  of  these  topics 

specifically;  and  to  derive  there-from  concrete  elements  of  the  solution  of  the  study  problem  to  be  manifest  in 
study  conclusions  and  recommendations.  In  all  cases,  the  Task  Group  was  careful  to  consider: 

•  The  diversity  in  the  existing  practices  and  technical  postures; 

•  Commonality  in  practice  or  in  dealing  with  potential  issues;  or 

•  Innovative  approaches  considered  to  be  auspicious  but  not  in  fact  part  of  the  experience  of  any  of  the 
organizations  and  enterprises  of  the  respective  Group  members. 

3.2  GENERAL  DISCUSSION  OF  EFFORT  ELEMENTS 

By  way  of  context,  comments  relating  to  scope  of  activity  and  Concept  of  Operations  (CONOPS)  of  the 
Group’s  effort,  and  associated  transaction  protocols  as  well  as  to  relationships  among  components  of  the 
Group’s  effort  are  introduced  first. 
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The  effort  of  the  MSG-058  consisted  of  a  series  of  working  meetings  augmented  with  the  execution  of  actions 
identified  therein  in  the  intervals  between  formal  working  meetings.  The  effort  of  each  meeting  was  decided 
in  advance  and  published  as  a  meeting  agenda.  Naturally,  the  differential  interests  of  the  Group  members  and 
national  participation  suggested  that  one  or  another  Group  member  might  lead  deliberation  for  topic  areas  of 
special  interest  or  competency;  nevertheless,  all  deliberations  were  conducted  by  the  committee-of-the-whole, 
operating  as  a  peer-group,  wherein  all  significant  decisions  were  made  as  matters  of  consensus  across  the 
entire  Group.  Group  efforts  were  coordinated  by  means  of  collaboration  workspace  information  technology 
resources,  wherein,  all  records  of  meetings,  decisions,  actions,  and  collateral  information,  were  conscientiously 
recorded  and  will  be  made  available  for  inspection  by  interested  parties  in  future  or  related  efforts.  The  use  of  the 
collaboration  environment  was  particularly  valuable  in  supporting  the  compilation  of  the  Group’s  work-product 
-  whose  components’  authorship  responsibilities  were  allocated  to  Group  members  based  on  interest  and 
familiarity. 

The  schedule  of  Group  meetings  is  indicated  in  the  following  figure.  That  illustration  indicates  the  tactic  adopted 
by  the  Group  to  have  meetings  as  frequently  as  possible,  particularly  early  in  the  program  when  disparate 
practices  and  complex  concepts  requiring  face-to-face  interaction  for  adequate  resolution  were  at  issue. 


ID 

Task  Name 

Duration 

2007 

2008 

2009 

2010 

Qtr  4 

Qtr  1  Qtr  2  1  Qtr  3  1  Qtr  4 

Qtr  T  I  Qtr  2  1  Qtr  3  Qtr  4 

Qtr  1  |  Qtr  2  |  Qtr  3  Qtr  4 

Qtr  1  1  Qtr 

2  Qtr  3  Qtr  4 

1 

MSG-058  Effort  Start 

1  day? 

^  4.1 6 

2 

Meeting  1  Paris 

3  days 

1 

3 

Meeting  2  Stockholm 

3  days 

1 

4 

Meeting  3  Huntsville 

3  days 

1 

5 

Meeting  4  Quebec 

3  days 

1 

6 

Meeting  5  Madrid 

3  days 

1 

7 

Meeting  6  Oslo 

3  days 

1 

8 

Meeting  7  Bucharest 

3  days 

1 

9 

Meeting  8  Huntsville 

3  days 

1 

10 

Meeting  9  Den  Haag 

3  days 

1 

11 

Meeting  1 0  Bucharest 

3  days 

1 

12 

Meeting  1 1  Quebec 

3  days 

1 

13 

Meeting  1 2  Orlando 

3  days 

1 

14 

End 

1  day? 

+  1 0/1 

Figure  3-1:  Calendar  Relationship  of  Meeting  Activities  Across  Which  Effort  was  Distributed. 


A  rough  indication  of  the  logical  and  activity-flow  relationships  among  the  Group’s  activities  regarding  topics 
of  special  import  is  provided  in  the  figure  following.  These  logical  relationships  and  the  nature  of  particular 
activities  are  discussed  in  considerable  detail  below. 
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Figure  3-2:  Logical  and  Activity  Flow  Relationships  Among 
Principal  Efforts  Comprising  the  MSG-058  Effort. 


Finally,  the  effort  of  the  Group  and  its  respective  domains  of  interest  and  resulting  meta-products  is  to  be 
understood  in  context  of  the  diagram  of  Figure  3-3  below.  There,  the  Group  executes  the  MSG-058  program 
by  way  of  Business  Process  Invention.  The  Group  product  document  specifies  conceptual  model  process  to  be 
conducted  by  practitioner  during  Business  Process  Practice,  yielding  the  conceptual  model  artefact  for  the 
specific  mission  space  and  model-simulation  intended. 
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Figure  3-3:  Mind-Map  Style  Illustration  of  the  Scope-of-Effort 
and  Domain-of-lnterest  of  the  MSG-058  Task  Group. 


Specific  topic  areas  of  effort  undertaken  by  the  Task  Group  included  the  following: 

•  National  Conceptual  Modeling  Practice  Expository  Briefings. 

•  Issue  Identification  and  Analysis. 

•  Stakeholders  and  Study  Scope  and  Objective. 

•  Terminology  and  Concepts. 

•  Analytical  Framework  and  Ontological  Perspective. 

•  Standards  Review  and  Evaluation. 

•  Process,  Product  and  their  Relationships. 

•  Process  Specification  Expression. 

•  Conceptual  Model  Process  Elements. 

•  Conceptual  Model  Documentation. 

•  Task  Group  Work-Product  Generation. 

•  Coordination  with  SISO  for  Generation  of  Subsequent  SISO/IEEE  International  Best-Practice  Standard. 
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For  each  topic  area  identified  above,  we  will  address  briefly: 

•  Introduction  and  background; 

•  Current  circumstance; 

•  Approach; 

•  Risks  and  risk-amelioratives; 

•  Relationships; 

•  Findings;  and 

•  Conclusions  and  recommendations. 

3.2.1  National  Conceptual  Modeling  Practice  Expository  Briefings 

Naturally,  members  of  the  Group  convened  to  execute  MSG-058  effort  brought  with  them  both  their  personal 
and  their  national  Institutional  preconceptions  and  practices  relevant  to  conceptual  modeling.  Therefore,  in  order 
to  assay  the  range  of  interests,  competencies,  and  richness  of  perception  and  experience,  the  systematic  review  of 
existing  conceptual  models  practice  was  considered  prudent.  Therefore,  Task  Group  member’s  national 
representatives  briefed  in  turn  their  respective  practices  for  conceptual  modeling,  and  those  sample  practices 
were  compiled  into  the  Group’s  collaborative  environment  for  future  reference. 

As  expected,  the  range  of  preconceptions  and  styles  of  operations  in  conceptual  modeling  practice  proved  to 
be  exceptionally  diverse.  Differentials  exist  among  presumptive  academic  underpinnings,  scope  assumed  to  be 
included  in  conceptual  modeling,  techniques  for  educing  and  documenting  conceptual  models  and  for  their 
use  within  the  various  enterprise  environments  represented.  This  diversity,  while  challenging,  was  considered 
by  the  Group  as  opportunistic  by  virtue  of  its  providing  a  constructively  broad  scope  to  the  Group’s  deliberations 
and  establishing  a  suitably  broad  basis  of  implicit  requirements  for  any  best-practice  work-product  developed 
and  recommended  by  the  Group.  Consequently,  potential  risk  in  task  scoping  and  ecumenical  consideration  of 
established  preferred  practices  were  considered  to  be  assuaged. 

Review  of  existing  practices  familiar  to  the  Group  proved  a  profitable  initial  transaction.  It  did  in  fact  serve  as 
a  suitable  basis  for  framing  the  work  process  for  the  remainder  of  the  program,  and  particularly  reinforced  the 
sense  that  a  consensus-based  effort  was  prudent. 

3.2.2  Issue  Identification  and  Analysis 

Pursuant  the  revelation  of  Task  Group  members’  respective  conceptual  modeling  practices;  it  was  observed 
that  a  variety  of  topics  might  reasonably  be  specially  designated  ‘issues’  -  that  is,  topics  whose  deep  appreciation 
and  consensus  resolution  by  the  Group  members  would  likely  be  necessary  to  the  successful  completing  of  the 
MSG-058  effort. 

The  Group’s  approach  to  issue-identification  and  resolution  is  described  in  detail  in  Annex  D.  Significantly, 
however,  a  deliberate  effort  was  made  to  identify  issues  related  to  each  of  four  perspectives: 

1)  General  and  administrative  conduct  of  the  Task  Group  tasking; 

2)  Constraints  associated  with  the  program  of  work  defined  in  the  tasking  guidance; 

3)  Technological  considerations  arising  out  of  the  subject  matter  entailed  in  conceptual  modelling;  and 
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4)  Considerations  related  to  the  generation  of  work-products  necessary  and  sufficient  to  accomplish  the 
mission  of  MSG-058. 

In  each  case,  actions  necessary  to  resolve  such  issues,  and  the  identification  of  the  entailments  of  such 
resolution  to  technology,  product,  program,  and  meta-process  for  the  Task  Group’s  effort,  were  identified. 

This  approach  revealed  what  proved  to  be  nineteen  (19)  issues  deemed  worthy  of  attention  in  four  (4)  categories: 

1)  Circumstance  and  Analytical  Context; 

2)  Intention; 

3)  Product  Development  and  Deployment;  and 

4)  Technical  Considerations. 

Of  the  total  set  of  issues  explicitly  identified,  five  (5)  topics  were  accorded  such  criticality  that  special  work 
efforts  were  conceived  and  executed  for  their  resolution  and  the  remediation  of  such  risks  as  were  considered 
to  be  related  thereto.  In  priority  order,  these  issues  were: 

•  Stakeholder  Analysis  and  Context; 

•  Scope  and  Definition; 

•  Relationship  to  Standards; 

•  Specification  of  Conceptual  Model  Management  Process;  and 

•  Specification  of  Conceptual  Model  Artefact. 

Each  is  addressed  in  the  text  of  this  report  at  a  level  of  indenture  no  higher  than  two  (i.e.,  n.m.). 

Naturally,  early  issue  identification  had  profound  implications  for  the  establishment  of  a  detailed  program  of 
effort  by  the  Group.  The  Task  Group’s  approach  to  concern  for  identification  and  resolution  of  critical  issues 
had  far-reaching  implications  for  the  subsequent  effort,  and  the  work-product  of  which  this  report  and  its 
enclosed  best-practice  recommendations  consist. 

3.2.3  Stakeholders  and  Study  Scope  and  Objective 

In  the  course  of  the  Task  Group’s  deliberations,  it  became  apparent  that  conceptual  modeling  must  be 
practiced  in  context  of  modeling  a  simulation  enterprise-scope  activity.  Further,  it  was  clear  that  the  nature  of 
conceptual  modeling  shared  many  of  the  practices  related  to  ‘user-needs’,  and  ‘requirements’  management 
practices  typical  of  systems  engineering  disciplines.  For  both  these  reasons,  the  need  to  be  explicit  regarding 
the  identification  of  stakeholder  roles,  their  associated  processes,  and  responsibilities  was  evident.  At  the  least, 
the  Group’s  expression  of  conceptual  models  best-practice  would  need  to  ‘speak  to’  significant  stakeholder 
communities  -  for  which  purpose,  the  Group  needed  to  be  appropriately  sensitive  to  those  roles. 

Consequently,  the  MSG-058  Task  Group  devoted  considerate  attention  to  identifying  and  characterizing 
stakeholder  roles,  and  to  including  in  our  analysis  such  use-cases  as  seemed  prudent  both  to  understand  the 
implications  of  necessary  diversity  of  stakeholder  populations  in  M&S  enterprise  environments  and  to 
communicate  successfully  to  all  parties  those  entailments. 

The  results  of  this  analysis  are  addressed  more  fully  in  Section  4.3  Conceptual  Modeling  Enterprise 
Stakeholders,  below;  and  further  explication  is  therefore  deferred,  except  to  emphasize  the  degree  to  which 
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stakeholder  analysis  and  respect  for  stakeholder  diversity  and  peculiarity  are  necessary  conditions  for 
understanding,  let  alone  employing  the  best-practice  guidance  contained  herein. 

Regarding  the  study  scope  and  objective,  analysis  effort  addressed  primarily  the  class  of  conceptual  model 
being  considered,  and  the  analytical  disciplines  considered  necessary  and  sufficient  for  subject  models  to  be 
managed  over  their  life  cycle. 

Conceptual  models  for  simulations  relating  to  military  mission  space  domains  were,  according  to  the  tasking 
guidance,  the  relevant  scope.  In  fact,  however,  considering  the  breadth  of  the  adjective  ‘military’  in  its  own 
referential  scope  (covering  most  of  the  mission  space  elements  considered  typical  of  non-military  mission- 
spaces  and  certainly  passing  well  beyond  simple  war-fighting  operations  to  encompass  logistics,  materiel 
management,  personnel  health  and  safety,  operational  security,  communications,  etc.),  and  considering  how 
generic  most  of  the  ideas  associated  with  conceptual  models  in  general  and  the  pragmatic  conceptual  models 
guidance  eventually  derived;  the  scope  of  applicability  of  the  Group’s  work-product  is  scarcely  proscribed  by 
its  ‘military’  appellation. 

Likewise,  given  the  interest  of  conceptual  model  management  (development,  documentation,  storage,  retrieval, 
re-use,  sharing,  etc.),  during  the  conceptual  modeling  life-cycle,  together  with  the  not  incidental  relationships  of 
systems  engineering  (applied  here  to  simulation  systems)  and  enterprise-context  operations  across  considerable 
institutional  scope  (e.g.,  national  and  NATO  international);  very  little  constraint  accrued  to  the  processes 
recommended,  particularly  with  respect  to  requirements  management  and  stakeholder  sensitivity. 

3.2.4  Terminology  and  Concepts 

In  many  scientific  domains,  terminology  is  critical,  see  Annex  I.  Practitioners’  shared  appreciation  of  the  state  of 
evolution  of  the  field  of  endeavour,  and  their  fundamental  capacity  to  communicate,  collaborate  and  cooperate 
depend  upon  the  existence  of  a  well-established  vernacular  that  is  shared  by  the  community-of-practice. 

Often,  such  terminology  is  available  through  the  efforts  of  past  researchers  -  especially  when  the  discipline  is 
mature  (or  simple),  taught  systematically,  and  appreciated  widely  across  the  community.  Conceptual  modeling 
is  not  such  a  discipline.  While  its  roots  in  the  ‘first-philosophies’  of  epistemology  and  ontology  are  deep, 
its  explicit  practice  in  modeling  and  simulation  is  relatively  new.  Conceptual  modeling  terminology  is  further 
confounded  by  the  overloading  or  multiple  meanings  of  such  keywords  such  as:  ‘entity’,  ‘model’,  ‘concept’, 
‘relationship’,  ‘attribute’,  ‘predicate’,  etc.  Further,  the  presumption  of  one  or  another  conceptual  technique, 
schema  or  notation  leads  promptly  to  terminological  ambiguity.  Finally,  in  an  international  working  group 
doing  business  in  English,  some  challenges  to  terminological  consistency  are  to  be  expected. 

The  approach  of  the  MSG-058  was,  from  the  start,  to  be  scrupulously  precise  in  vocabulary  usage,  and  to 
record  such  determinations  as  seem  best  in  a  lexicon  that  has  evolved  over  the  course  of  the  program  and  that 
is  published  as  Annex  J  to  the  present  volume.  The  structure  of  that  annex  is,  in  fact  rather  a  glossary  than  a 
formal  definitional  lexicon,  in  which  alternative  definitions,  interpretation,  commentary  and  usages  are  cited 
in  hopes  of  communicating  not  only  the  sense  of  terms  as  used  in  the  report  text,  but  also  to  communicate  to 
the  reader  the  range  of  nuance  which  lexical  vocabulary  may,  under  one  circumstance  or  another  assume. 
In  doing  so,  the  Task  Group  hopes  both  to  communicate  precisely  its  own  effort,  determinations  and  findings, 
but  also  to  share  with  the  reader  the  degree  to  which  nuance  and  potential  ambiguity  persist  in  a  subject  only 
lately  approaching  the  maturity  which  modeling  and  simulation  practitioners  desire  and  deserve. 

This  explicit  convergence  on  vocabulary  usage,  combined  with  the  consensus-based  protocols  characteristic  of 
all  the  collaborative  effort  of  the  Group  has  resulted  in  acceptable  vocabulary  consistency  at  least  within  the 
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context  of  the  study.  Given  that  the  intention  of  NATO  is  to  have  the  present  work  continued  in  context  of 
international  standards-development  bodies,  however,  concern  for  lexical  precision  cannot  be  ignored. 
The  reader  is  particularly  referred  to  the  Glossary,  Annex  J,  for  citations  and  explication  of  vocabulary  used  in 
the  body  of  this  report. 

Continued  aggressive  pursuit  of  vocabulary  and  subject-matter  semantic  consistency  in  conceptual  models 
best-practice  guidance  is  strongly  recommended. 

3.2.5  Analytical  Framework  and  Ontological  Perspective 

Conceptual  modeling  entails  the  abstraction  of  some  ‘referent’  domain’  resulting  in  a  description  of  that 
domain  suitable  for  managing  its  ‘representation’  by  artificial  means  such  as  by  a  model  or  simulation. 
Pursuing  the  MSG-058  TAP  TOR  entails  assuming  one  or  another  ‘analytical  frame’  from  which  to  address 
consideration  of  this  process  and  generation  of  prescriptive  guidance  to  practitioners.  This  analytical  frame  is 
in  effect  one  or  another  way  of  looking  at  the  world.  Alternatives  of  such  frames  include  for  instance: 
ontology,  systems  engineering,  software  engineering,  and  knowledge  management;  together  with  a  wide 
variety  of  tools  and  techniques  for  pursuing  explication  of  each  frame,  such  as  model  driven  architecture, 
Knowledge  Acquisition  /  Knowledge  Engineering  (KA/KE)  assets,  systems  engineering  tools,  etc. 

The  Task  Group  debated  the  question  of  an  appropriate  analytical  frame  or  prospective  from  which  to  proceed, 
investigating  closely  a  wide  variety  of  options  such  as  was  manifest  in  the  knowledge  and  practices  of  the 
member  national  participants  and  active  individual  members.  Finally,  the  Task  Group  elected  an  ontology-based 
perspective,  and  proceeded  to  create  a  systematic  process  that  reflected  this  foundational  perspective,  while 
drawing  from  multi-disciplinary  perspectives  to  make  the  best-practice  guidance  familiar  and  pragmatically 
practical  to  the  target  practitioner  and  associated  stakeholders. 

In  short,  ‘ontology’  asks  the  rhetorical  question:  What  is  there?  In  the  present  context,  more  specific  formulations 
might  be:  What  do  we  care  about,  or  alternatively: 

•  What  is  it  necessary  to  represent  in  a  model  or  simulation  in  order  for  the  resulting  product  to  serve  its 
intended  use;  and 

•  What  is  necessary  to  prescribe  about  the  simulation  artefact  itself  for  it  to  be  likewise  useful?  Given 
this  knowledge,  the  next  question  that  must  be  addressed  is:  How  can  one  select,  and  document  the 
contents  of  such  representations? 

Two  complimentary  risks  are  associated  with  the  Group’s  addressing  selection  of  analytical  frame.  On  the  one 
hand,  failing  to  establish  an  intellectually  secure  frame  leaves  the  establishment  of  a  conceptual  model  a 
proverbial  foundation  of  sand.  On  the  other  hand,  making  the  proceedings  and  consequent  product  of  the 
Group  too  explicitly  bound  to  potentially  abstruse  academic  precepts,  constructs,  and  inferences  risks 
alienating  potential  practitioners.  The  risk  management  tactic  adopted  by  the  Group  was  to  dig  deep  and  build 
on  firm  foundations,  and  to  report  those  deliberations;  but  to  efface  such  considerations  from  the  pragmatic 
process  guidance  provided  in  the  ‘best-practice’  prescriptive  guidance  in  the  document’s  Annexes  G  and  H. 

To  this  effect,  the  subject  is  explicitly  treated  separately  in  Annex  E  -  Explanation  of  Fundamental  Concepts 
for  Conceptual  Model  Frame-of-Reference.  In  addition,  copious  references  are  provided  in  Annex  K  - 
Bibliography,  that  document  the  fundamental  ontological  perspective  upon  which  many  of  the  Task  Group’s 
deliberations  were  fundamentally  based.  Nevertheless,  this  analysis  and  exposition  and  the  academic- 
intellectual  underpinnings  it  deploys  can  be  skipped  for  the  sake  of  convenience  or  for  lack  of  explicit  interest 
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by  the  reader  without  detracting  from  either  the  comprehensibility  or  the  utility  of  the  concrete  best-practice 
guidance  contained  herein. 

3.2.6  Standards  Review  and  Evaluation 

The  present  document  -  particularly  its  operationally  concrete  and  procedurally  prescriptive  guidance  contained 
in  Annex  G  -  Conceptual  Modeling  Process  Activity  Description  and  Annex  H  -  Conceptual  Model  Product 
Description  -  is  itself  a  ‘soft’  standard,  of  type  usually  denoted  ‘best-practice’.  On  the  other  hand,  the  analysis 
entailed  in  deriving  such  practice  and  the  expression  of  the  practice  itself  entails  consideration  of  standards  of  a 
wide  variety  of  types. 

A  significant  effort  by  the  MSG-058  Task  Group  was  to  review  standards  perceived  as  potentially  relevant  to 
the  subject  analysis  and  prescriptive  guidance;  to  analyze  the  special  significance  of  such  candidate  standards; 
and  to  invoke  such  standards  (individually,  by  reference,  or  more  often  by  class)  in  either  the  analysis  reported 
herein  or  the  procedural  guidance  appended. 

The  strategic  approach  of  the  Group  was  to  leverage  existing  standards  instances  and  standards  types  to  the 
greatest  extent  possible  in  order  to  reduce  redundancy  and  invoke  guidance  re-use  wherever  possible. 
At  the  same  time,  however,  we  have  been  scrupulous  to  avoid  recommending  specific  standards  when  a  class 
of  standards  could  be  cited  and  the  choice  of  a  particular  standard  left  to  the  discretion  of  the  practitioner. 

The  subject  of  standards  is  detailed  in  Annex  F  -  Standards,  but  should  be  interpreted  throughout  as  an  exercise 
in  coaching  of  the  practitioner  toward  more  systematic  professional  and  productive  practice  commensurate 
with  the  mores  of  his  own  enterprise  environment. 

3.2.7  Process,  Product  and  their  Relationships 

Within  this  document,  there  are  two  primary  processes  described,  to  be  executed  by  one  or  another  of  two 
agencies,  and  resulting  in  one  or  another  of  two  significant  work-products.  In  this  section,  we  identify  briefly 
these  processes,  agents,  and  work-products  and  indicate  their  relationships  before  proceeding  with  more 
detailed  descriptions  in  following  text  sections.  In  order  to  establish  a  perceptual  frame  of  the  set  of  agents, 
activities,  and  products  that  comprise  the  development  of  this  document  and  its  included  best-practice 
guidance  as  well  as  the  execution  of  that  guidance  and  the  generation  of  consequent  conceptual  models, 
the  reader  is  referred  to  the  following  Figure  3-4. 
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Figure  3-4:  Relationships  Among  Agents,  Processes,  and  Products  Associated  with 
Subject  MSG-058  Effort  and  its  Consequential  Conceptual  Modeling  Practice. 


As  indicated  in  the  diagram,  the  MSG-058  Task  Group  itself  performed  the  activity  of  analyzing  conceptual 
modeling  and  formulating  requisite  best-practice  guidance.  The  persistent  information  product  resulting  from 
that  activity  is  the  best-practice  guidance  specification  contained  within  this  document  in  Chapters  5  and  6  and 
in  the  Annexes  G  and  H.  The  causal  relationship  between  this  activity  and  its  consequent  resulting  work- 
product  is  indicated  by  the  blue  arrow  numbered  1.  Subsequently,  the  M&S  conceptual  modeling  development 
practitioner  is  expected  to  execute  the  prescriptive  best-practice  to  produce  the  conceptual  model  itself 
This  productive  result  is  indicated  by  the  blue  arrow  number  2.  Finally,  the  activity  conducted  by  conceptual 
modeling  practitioners  and  the  work-product  produced  thereby  are  shown  to  be  affected  by  the  best-practice 
guidance  specification  through  influence  designated  by  red  arrows  3  and  4  respectively.  With  this  activity  and 
influence  relationships  in  mind,  comments  follow  relating  to  process  and  product  specification  generated  by 
the  Task  Group. 

3.2.8  Process  Specification  Expression 

The  MSG-058  Task  Group  explicitly  addressed  consideration  of  the  most  appropriate  form  of  specification  of  its 
guidance  to  conceptual  model  stakeholders.  Process  specification  itself  admits  to  a  wide  variety  of  schemas, 
notations,  and  seminal  notions.  Since  the  Group  could  not  provide  multiple  alternative  specifications,  and  chose 
not  to  endorse  a  single  specific  notational  or  conceptual  frame  for  process  specification,  we  resorted  to  what  was 
held  to  be  a  generic  or  vanilla  specification  schema  -  without,  however,  falling  prey  to  least-common- 
denominator  information  content.  The  meta-process  specification  schema  employed  (employed  as  partial  graphic 
illustrations  in  the  text  of  Chapters  5  and  6  and  defined  in  detail  in  association  with  the  Annex  G  wherein  it  is 
employed  to  communicate  the  recommended  conceptual  modeling  processes)  is  considered  to  be  sufficient, 
complete,  consistent,  and  formally  equivalent  to  most  commonly  employed  process  specification  schemas  and 
notations,  and  implementing  Commercial-Off-The-Shelf  (COTS)  tools. 

Naturally,  the  practitioner  is  encouraged  to  use  schemas,  tools,  and  techniques  to  specify  the  objective  system 
processes  such  as  constitute  the  content  of  the  actual  conceptual  model  as  are  deemed  appropriate  to  the 
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enterprise  context  in  which  execution  of  conceptual  modeling  is  to  be  conducted.  In  that  way,  considerations 
such  as  machine  readability,  COTS  tools  availability,  and  compliance  with  enterprise  process  specification 
standards  are  well  within  the  discretion  of  the  practitioner-agent  for  the  benefits  intended  thereby. 


3.2.9  Conceptual  Model  Process  Elements 

Moving  from  consideration  of  meta-process  specification  practiced  in  formulating  the  best-practice 
instructions  proffered  below,  to  the  actual  prescription  of  elements  of  process  models  considered  necessary 
and  sufficient  to  contain  and  communicate  model  and  simulation  object  and  process  semantic  content; 
the  Task  Group  again,  resorted  to  the  use  of  nominative  or  generic  conceptual  primitives  that  were  considered 
equivalently  powerful  as  specific  conventional  notations  and  styles  of  object  and  process  specification. 
Supporting  on  the  one  hand,  object  qualia  such  as:  class  membership,  generalization  and  specialization, 
inheritance  of  attributes,  membership  and  client  server  associations,  etc.,  and  on  the  other  hand,  process  constructs 
as  sequence  and  concurrency,  causal  effect,  temporal  synchronization,  process  composition  and  encapsulation, 
etc.;  the  notation  used  in  the  subject  best-practice  specification  is  considered  likewise  sufficiently  general  to 
serve  all  needs,  and  sufficiently  suggestive  and  non-binding  to  be  able  to  be  implemented  by  the  use  of  such 
specific  process  primitives  as  are  to  be  found  in  typical  practices  and  tools. 

Once  again,  the  practitioner’s  discretion  to  use  such  constructs  and  notations  as  are  commensurate  with 
technical,  programmatic,  and  enterprise  constraints  is  protected,  while  the  sufficiency  of  actual  conceptual 
models  to  contain  necessary  and  sufficient  information  is  guaranteed. 

3.2.10  Conceptual  Model  Documentation 

Consideration  of  the  conceptual  model  documentation,  as  discriminated  from  both  the  conceptual  model 
generation  and  its  specific  information  content  generated  for  one  or  another  application,  was  a  matter  of 
particular  concern  to  the  Group.  That  documentation  activity  is  yet  another  meta-process  -  that  is,  one  of  the 
operations  by  the  conceptual  model  management  practitioner  whereby  the  conceptual  model,  having  been 
abstracted  from  appreciation  of  the  subject  mission-  and  simulation-space,  is  made  manifest  in  persistent, 
communicable,  achievable,  and  recoverable  form,  that  can  serve  as  well  as  a  reference  information  artefact 
from  which  model  or  simulation  implementation  may  proceed  and  subsequently  be  verified.  Documentation 
artefacts  resulting  from  practitioners’  efforts  were  considered  to  be  appropriately  subject  to  best-practice 
guidance;  and  providing  instruction  to  practitioners  on  recommended  structural  form  and  general  semantic 
content  of  such  artefacts  was  felt  to  be  a  significant  component  of  best-practice  guidance. 

In  order  to  influence  conceptual  model  artefacts  generated  pursuant  to  election  and  execution  of  best-practice 
guidance  by  conceptual  modeling  stakeholders,  the  Task  Group  elected  to  provide  to  the  conceptual  modeling 
practitioner  dual  forms  of  guidance  (i.e.,  process  and  product)  whereby  one  perspective  addressed  conceptual 
model  development  process  and  the  other  addressed  the  resulting  conceptual  model  product  document 
artefact.  Having  addressed  conceptual  modeling  process  elements,  as  described  above,  and  having  resolved  to 
provide  guidance  to  practitioners,  the  Group  determined  to  address  the  characteristics  recommended  for  the 
consequent  conceptual  model  ‘Product’  itself,  namely  the  document  (or  other  form  of  persistent  capture  of  the 
conceptual  model’s  semantic  content)  expected  to  be  generated  by  the  practitioner  in  accomplishing  his 
objective  conceptual  modeling  effort. 

Since  a  necessary  criterion  for  completion  of  conceptual  model  development  and  use  is  the  generation  of  a 
persistent  capture  of  information  relevant  to  the  conceptual  model  development,  contents,  life-cycle  management, 
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and  uses,  the  Task  Group  resolved  to  provide  necessary  and  sufficient  guidance  for  the  generation  of  such 
documentation.  Guidance  related  to  conceptual  model  product  artefacts  is  ‘dual’  to  process  guidance 
addressed  above;  and  the  result  of  the  pursuit  of  this  approach  is  Chapter  5  and  Annex  G  of  this  report. 
In  effect,  the  Task  Group  determined  that  if  the  conceptual  modeling  practitioner  executed  the  Process 
Guidance  of  Chapter  5  in  this  report;  then  there  would  result  a  documentary  product  whose  desired 
characteristics  are  described  in  Chapter  6  and  Annex  H  of  this  report.  Product  Guidance,  therefore,  contains 
specification  of  expected  information-content  and  expositional-structure  of  the  resulting  conceptual  model 
documentation  itself. 

Throughout  the  Task  Group’s  deliberations  and  everywhere  in  its  derived  prescriptive  guidance,  emphasis  of 
data  contents  over  expository  structure  was  assumed.  Attention  to  capture  of  information  necessary  and 
sufficient  to  support  the  conceptual  modeling  facet  of  M&S  enterprise  operations  of  the  specific  M&S 
community  of  practice  for  which  the  conceptual  model  is  intended  was  kept  clearly  in  mind  and  made  manifest 
to  the  greatest  degree  possible  in  recommended  practice  guidance  processes  prescribed  below.  This  commitment 
was  modulated  with  considerable  sensitivity  to  avoiding  too  restrictive  prescription  of  documentary  practice  that 
local  or  national  standards  could  not  conveniently  be  employed. 

The  Task  Group  concluded  that  by  providing  complimentary  process  and  product  prescriptive  guidance, 
the  prospect  of  successful  completion  of  conceptual  modeling  practitioners’  efforts  and  the  result  of  appropriate 
conceptual  model  documentation  might  be  assured. 

3.2.11  Task  Group  Work-Product  Generation 

The  Task  Group  was  well  aware  that  the  results  of  the  effort  were  expected  to  be  a  documentary  report  serving 
the  following  functions: 

•  Establishing  the  context  of  the  subject  effort  by  reciting  background  circumstances  and  Task  Group 
objectives; 

•  Providing  a  recitation  of  the  effort  of  the  Group  sufficient  to  illustrate  how  their  determinations  and 
findings  were  arrived  at,  and  establishing  the  credibility  of  the  group  process  and  consequently  the 
relevance  of  its  effort;  and 

•  Capturing  prescriptive  guidance  for  M&S  conceptual  modeling  practitioners  regarding  the  generation 
and  documentation  of  subject  conceptual  models  commensurate  with  NATO  M&S  enterprise  wants 
and  needs  on  the  one  hand  and  the  need  for  explicit  guidance  to  practitioners  occupied  in  conceptual 
model  management  on  the  other. 

According  to  the  “TERMS  OF  REFERENCE  RTG  on  Conceptual  Modeling  for  M&S  MSG-058,  RTG-038:”, 
the  Task  Group  was  to  “Draft  a  guidance  document  on  conceptual  modeling  that  can  be  used  by  different 
stakeholders  (sponsor/user,  project  manager,  subject-matter  experts,  V&V  agents,  developers,  etc.)”,  with  the 
admonition  that:  “The  final  work  will  be  to  provide  a  tailorable  set  of  guidance  to  the  M&S  community  on 
conceptual  modeling”  ...  provided  as  a  “Technical  Report”...  which  final  report  should  be  a  “guidance 
document  freely  available  to  the  international  community”. 

The  Group’s  approach  to  the  generation  of  this  work-product  was  to  execute  the  following  process: 

•  Establish  subject  matter  suitable  for  inclusion  in  the  product; 

•  Agree  on  the  expository  outline  deemed  most  clearly  to  accomplish  the  functions  cited  above; 
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•  Negotiate  voluntary  adoption  of  writing  assignments  among  the  Group  members  according  to 
personal  familiarity  with  the  subject  matter  in  respective  documentary  outline  sections,  and  equitable 
distribution  of  workload  among  the  Group  participants; 

•  Complete  storyboard  specifications  of  subject-matter  exposition,  including  attention  to  elements 
indicated  in  the  NATO  Conceptual  Model  Storyboard  template; 

•  Review  in  plenary  the  storyboards  and  establish  consistent  plan  of  explication; 

•  Draft  respective  sections; 

•  Compile  and  integrate  full  documentary  report;  and 

•  Conduct  review  of  document  by  all  members  of  the  Task  Group  and  determination  of  consensus 
support  of  final  work-product. 

While  small  risk  was  expected  relating  to  consistency,  correctness,  and  lucidity  of  explanations  of  the 
individual  sections  (due  to  conscientious  record-keeping  by  the  Task  Group  via  its  collaborative  environment 
during  effort  execution  and  the  personal  and  professional  qualifications  and  competencies  of  the  authority  team), 
the  formal  composition  process  implemented  served  to  ensure  consistency  and  economic  documentation  of  the 
Group  effort  and  its  consequent  determinations  and  findings. 

One  significant  decision  was  to  produce  one  report  work-product;  within  which  the  subject-recommended 
best-practice  standard  was  contained.  Consequently,  Chapter  4  “Conceptual  Modeling  Best-Practice  Guidance 
Introduction”,  Chapter  5  “Conceptual  Modeling  Process  Guidance”,  Chapter  6  “Conceptual  Model  Product 
Guidance”  and  their  accompanying  Annexes  G  -  “Conceptual  Modeling  Process  Activity  Descriptions”  and  H 
-  “Conceptual  Model  Product  Descriptions”  are  considered  appropriate  to  serve  as  stand-alone  as  prescriptive 
best-practice  guidance  and  to  be  proffered  to  the  NATO  and  SISO  communities  for  excision  and  publication 
for  the  reference  of  conceptual  model  management  practitioners  and  related  stakeholders. 

3.2.12  Coordination  with  SISO  for  Generation  of  Subsequent  SISO/IEEE  International 
Best-Practice  Standard 

At  the  inception  of  Task  Group  activity,  collaboration  with  other  international  standards  organizations  was 
anticipated  and  made  explicit  in  the  TOR  tasking.  In  particular,  the  intention  was  to:  “Foster  the  establishment 
of  the  [Task  Group  work-product]  guidance  document  as  a  SISO  standard.” 

The  desired  scope  of  prospective  collaboration  was  specified  as  “Liaison”  in  the  Terms  of  Reference  and  should 
be  established  with  the  following  organizations: 

•  MSG-054  Task  Group  on  “An  Overlay  Standard  for  Verification,  Validation,  and  Accreditation 
(VV&A)  of  Federations”. 

•  MSG-052  Task  Group  on  “Establishment  of  a  Knowledge  Network  for  Federation  Architecture  and 
Design”. 

•  The  coming  Task  Group  IST-075/RTG-034  on  “Semantic  Interoperability”  (Continuation  of  the  1ST 
group  ET-040  on  “Ontology  fusion”). 

•  Simulation  Interoperability  Standards  Organization  (SISO). 

•  Other  RTO  Task  Groups  as  required. 
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Means  for  implementing  such  collaboration  process  were  left  to  the  discretion  of  the  Task  Group  and  were, 
in  fact  pursued  to  the  greatest  extent  allowed  by  circumstances,  resources,  and  perceived  probability  of 
success  of  the  Task  Group’s  subject  tasking.  Interface  was  implemented  by  means  of  exchange  of  briefings 
publications  of  papers,  and  meetings  at  which  information  was  exchanged  on  current  state  of  effort  and 
expectations  for  immanent  progress. 

As  a  consequence  of  this  collaboration,  it  is  expected  that,  as  desired:  “The  final  report  should  be  a  ‘guidance 
document’  freely  available  to  the  international  community.” 


3.3  CONCLUSION 

Based  on  the  process  model  and  activity  of  the  Task  Group  described  in  the  preceding  sections,  the  contents  of 
Chapters  4,  5,  and  6  were  generated,  which  together  with  their  accompanying  annexes,  constitute  the 
recommended  best-practice  guidance  for  conceptual  modeling  for  Military  Models  and  Simulations. 


3-14 


RTO-TR-MSG-058 


Chapter  4  -  INTRODUCTION  TO  CONCEPTUAL 
MODELING:  BEST-PRACTICE  GUIDANCE 


ORGANIZATION 


In  the  previous  chapter,  we  addressed  the  conduct  of  MSG-058  and  identified  significant  issues  and  strategies 
associated  with  the  accomplishment  of  the  Task  Group’s  effort.  In  following  chapters,  we  present  exposition 
of  best-practice  guidance  process  and  product  finally  developed  and  recommended  to  the  conceptual  modeling 
practitioner  and  stakeholder  community  for  employment.  In  this  Chapter  4,  we  establish  the  conditional 
determinations  and  findings  upon  which  that  operational  best-practice  is  predicated.  The  discussion  following 
addresses  contextual  issues  of  scope  and  enterprise  context,  and  the  appreciation  of  the  stakeholder  community 
whose  wants,  needs  and  collaborative  participation  are  necessary  for  successful  conceptual  modeling. 
Foundational  and  pragmatic  ideas  related  to  specialized  vocabulary,  the  complementary  dyadic  conceptions  of 
representation  spaces,  and  best-practice  notational  conventions  are  introduced  in  anticipation  of  the  use  of  this 
terminology  and  these  concepts  in  the  formal  prescriptive  guidance  to  follow  in  Chapters  5  and  6.  Finally, 
we  comment  on  quality  attributes  of  conceptual  models  in  order  to  emphasize  the  necessity  to  verify  and  validate 
simulation  conceptual  models  in  much  the  same  way  as  simulation  artefacts  themselves  are  verified  and 
validated  as  a  fundamental  component  of  conceptual  model  quality  management. 


4.1  CONCEPTUAL  MODELING  OPERATIONAL  SCOPE 

While  the  scope  of  this  guidance  is  nominally  for  NATO  military  modeling  and  simulation,  the  approach 
taken  herein  is  to  provide  comprehensive  guidance  that  can  easily  be  adapted  and  tailored  to  individual 
enterprises  and  can  be  generalized  to  apply  to  alternative  domains.  Likewise,  this  guidance  is  intended  to  be 
general  enough  to  serve  as  a  foundation  for  subsequent  establishment  of  industry  standards  for  conceptual 
model  development  and  life-cycle  management  activities. 

Throughout  MSG-058  deliberations,  the  Task  Group  found  it  convenient  to  keep  in  mind  two  contextual 
perspectives  of  conceptual  modeling  and  conceptual  models  -  both  simple  -  each  suggestive  of  the  place  of 
conceptual  models  and  modeling  in  simulation  life-cycle  development  paradigms.  Such  pictorial  paradigms 
served  to  remind  the  Group  at  once  of  the  intended  scope  of  deliberation  and  of  consequent  best-practice 
guidance  as  well  as  the  context  of  its  analysis  and  work-products. 

Consequently,  it  may  be  useful  to  consider  a  general  case  of  conceptual  modeling  as  shown  in  Figure  4-1, 
to  illustrate  that  any  conceptual  model  of  interest  may  be  of  a  particularly  simple  or  complex  domain  or 
problem  space,  which  can  also  benefit  from  these  best-practices. 
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Figure  4-1:  Conceptual  Model  Depicted  as  Intermediate  Artefact  Between  Real-World 
or  Mission  Space  Knowledge  and  Simulation  Artefact  and  as  Element  in 
Progressive  Simulation  Life-Cycle  Development  Process. 


While  the  application  of  this  guidance  is  intended  to  be  broad,  the  scope  of  this  guidance  is  targeted  to  the 
conceptual  model  development  process,  and  only  provides  limited  best-practices  pertaining  to  the  rest  of  the 
conceptual  model  life  cycle.  And  while  the  development  of  quality  conceptual  models  enables  other  life-cycle 
characteristics  such  as  interoperability  and  transformation,  guidance  to  execute  the  additional  stages  is  beyond 
the  scope  of  this  document.  Figure  4-2  provides  a  context  for  the  guidance  provided  here,  as  related  to  the 
larger  conceptual  model  life  cycle. 
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The  approach  for  explication  of  this  guidance  is  to  discuss  the  role  a  conceptual  model  should  have  in  the 
M&S  development  process,  propose  scope  and  terms  of  reference,  expand  and  illustrate  new  and  novel 
concepts,  propose  an  analytical  framework,  define  a  thorough  but  tailorable  process  and  associated  products, 
and  provide  Process  Activity  and  product  descriptions  for  reference. 


4.2  ENTERPRISE  CONTEXT 

One  particularly  significant  component  of  the  context  of  conceptual  modeling  is  the  institutional  or  business 
practice  environment  within  which  the  modeling  is  performed  and  within  which  its  value  is  expected  to  be 
realized.  In  the  text  that  follows,  we  introduce  the  idea  of  enterprise  context  by  discussing  how  modeling  and 
simulation  has  evolved  within  the  last  decades.  Next  we  define  ‘enterprise’  and  distinguish  between  ‘local’ 
operational  contexts  and  enterprise  contexts.  Several  implications  that  are  entailed  by  enterprise-based 
conceptual  modeling  operations,  including  both: 
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•  The  influence  of  enterprise  concepts-of-operations  upon  conceptual  modeling  process  and  the  nature 
of  conceptual  models  themselves;  and 

•  The  entailments  of  conceptual  modeling  and  the  use  of  conceptual  model  artefacts  for  the  success  of 
the  enterprise  environment,  in  which  they  are  contained,  will  be  described. 

The  very  significant  perspective  of  the  control  of  quality  of  conceptual  models  over  their  life-cycle  evolution 
-  usually  designated  verification  and  validation  of  the  conceptual  model  -  are  addressed  in  a  following  section 
in  order  to  address  in  appropriate  detail  the  specific  place  of  conceptual  model  quality  management  in  enterprise 
contexts. 

4.2.1  Evolution  of  Operational  Context 

Modeling  and  simulation  in  general,  and  conceptual  modeling  in  particular,  are  being  conducted  in  different 
environments  in  recent  decades  than  previously. 

Heretofore,  M&S  (and  conceptual  modeling)  were  technical  specialties  that  were  conducted  by  individual 
staff,  largely  below  the  level  of  visibility  of  the  organization-level  management.  Conceptual  modeling  was 
itself  mostly  a  craft  competency;  and  its  conduct  was  private  to  the  simulation  developer  or  to  the  small  Group 
of  which  he  was  a  member.  Conceptualization  was  a  personal  skill,  seldom  conducted  at  even  Group  level  of 
visibility,  and  less  often  documented  at  all  but  instead  manifest  only  implicitly  in  the  simulation  products 
produced  by  individuals  or  development  Groups.  Simulation  development  efforts  were  modest  in  size  and  scope 
or  were  organic  within  one  or  another  user  community.  Simulations  were  seldom  shared,  re-used  or  operated  in 
combination  with  other  models  or  simulations;  and  there  was  little  appetite  or  motivation  for  explicit,  deliberate, 
public  conceptual  modeling  practice  and  products. 

More  recently,  M&S  has  become  a  significant  component  of  operations  within  organizations.  Consequently, 
M&S  and  their  attendant  conceptual  modeling  efforts  have  become  both  more  expensive,  and  more  critically 
valuable  to  the  organizations  within  which  they  are  conducted.  Expectation  of  M&S  re-use  and  interoperability, 
sensitivity  to  demonstrated  M&S  credibility  through  systematic  verification  and  validation,  and  the  persistence 
and  pervasiveness  of  use  of  simulations  within  and  beyond  organizational  boundaries  have  made  deliberate, 
public,  and  accountable  M&S  practice  in  enterprise  context  the  norm. 


4.2.2  Enterprise  Definition 

For  purposes  of  this  discussion,  the  following  definition  is  provided: 

Enterprise  n.  -  One  or  more  organizations  under  common  control.  Generally  refers  to  the  broadest 
scope  of  organization  and  operational  process  relevant  to  the  subject  discussion  rather  than  to 
individual  components  thereof 

NATO  and  national  defence  establishment  M&S  communities-of-practice  are  de  facto  enterprises  in  this  spirit 
when  the  investment,  development,  maintenance,  and  use  of  M&S  assets  are  concerned.  Naturally,  the  scope 
of  any  particular  enterprise  environment  depends  upon  the  circumstances  and  particularities  of  the  M&S 
operation  in  question;  but  in  most  cases,  questions  of  strategic  investment  in  M&S  policy,  practice  and 
implementation  has  as  its  scope  the  entire  NATO  community.  The  fundamental  need  for  successful  investment 
in  modeling  and  simulation  within  NATO  is  well  documented  and  broadly  recognized.  In  addition,  more  than 
a  few  efforts  have  been  conducted  to  assess  the  then-current  state,  prevalent  need,  and  recognized  gaps  of 
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business  practices  for  M&S,  and  the  deliberate  management  of  M&S  investment  to  achieve  necessary  and 
sufficient  state  of  mission  capability.  Such  efforts  have  included:  NATO  M&S  Conference  [1]  and  Study 
Group  [2]  activity;  initiatives  by  other  national  defence  establishments  [3];  efforts  by  professional  societies  to 
analyze  the  mechanisms  of  M&S  cost-effectiveness  [4]  [5]  [6]  [7][8];  and  academic  research  efforts  [9][10]. 

Enterprise-level  M&S  investment  requires  structure,  persistence  and  common  valuation  for  consistent 
execution.  To  paraphrase  a  quote  [11]  from  the  commercial  environment: 

Stand-alone  M&S  strategies  don  7  work  when  DoD  ’s  enterprise-wide  success  depends  on  the  collective 
value  created  across  the  organizations  that  influence  the  creation  and  delivery  of  value  derived  from 
investment  in  M&S.  Knowing  what  to  do  requires  understanding  DoD ’s  ecosystem  and  leadership ’s  role 
in  it. 

This  admonition  advances  the  fundamental  premise  that  commercial  businesses  exist  and  thrive  (or  not) 
within  the  context  of  a  business  environment  much  larger  than  exists  within  the  boundaries  of  an  individual 
firm;  and  that  to  succeed,  individual  firms  must  learn  to  recognize  and  create  value  within  The  ecosystem’  in 
which  they  exist.  The  article  defined  a  ‘business  ecosystem’  as  that  set  of  external  organizations  to  which  the 
success  of  your  organization  is  closely  tied,  those  for  which  critical  dependencies  exist.  The  key  to  maximizing 
value  on  an  enterprise  level  is,  as  is  implied  by  an  ‘ecosystem’  viewpoint,  understanding  who  shoulders  the 
costs,  and  who  potentially  derives  value  from  the  allocation  of  resources  to  M&S. 

4.2.3  Implications  of  Enterprise  Context  for  Conceptual  Modeling  Practice 

Enterprise  level  processes  and  products  are  required  for  all  components  of  the  M&S  life  cycle  within  the 
organization,  but  nowhere  more  than  in  the  area  of  conceptual  modeling. 

From  the  perspective  of  enterprise  operations,  several  implications  follow  for  conceptual  modeling  practice. 
These  influences  must  be  reflected  in  recommended  conceptual  modeling  best-practice,  and  constitute, 
in  fact,  a  substantial  set  of  the  requirements  for  such  practice.  Among  the  several  requirements  driven  by  the 
expectation  that  conceptual  models  will  inhabit  an  enterprise  environment  are  the  following: 

•  Stakeholder  Community  -  Conceptual  modeling  will  be  conducted  and  its  value  recovered  in  a 
community  or  practice  commensurate  with  the  scope  and  diversity  of  the  enterprise  participants. 
Concepts  invoked  to  develop,  understand,  share,  and  reuse  conceptual  model  artefacts  with  confidence, 
and  with  reasonable  expectation  of  accruing  the  benefits  of  shared  investment  require  that  all 
stakeholder  roles  be  carefully  defined  and  be  appreciated  as  pertaining  across  the  enterprise  scope. 

•  Process  Consistency,  Commonality  and  Tailor  ability  -  Processes  comprising  the  conceptual  model 
best-practice  must  be  appropriate  for  execution  in  a  NATO-diverse  constituency.  Best-practice  process 
elements  must  be  sufficiently  consistent  that  participation  in  conceptual  modeling  can  be  extended  across 
any  sub-set  of  the  NATO  M&S  community.  Practice  commonality  must  have  a  similar  domain  in  order 
that  suitable  common  ground  exist  from  which  NATO  M&S  constituents  may  fully  appreciate  both  how 
conceptual  models  were  achieved  and  what  their  contents  are,  once  produced.  Conceptual  modeling 
processes  and  products  must,  nevertheless,  be  sufficiently  tailorable  so  that  they  can  be  socialized  by  any 
particular  sub-set  of  the  enterprise  to  which  they  will  particularly  pertain  -  and  they  must  be  sufficiently 
tailorable  as  to  admit  the  specific  referent  subject  matter,  conceptual  constructs,  and  representational 
schemas  as  may  be  elected  by  one  or  another  sub-set  of  the  stakeholder  community. 

•  Product  Consistency  -  Conceptual  model  product  consistency  must  be  sufficient  that  the  library 
of  conceptual  models  deployed  and  used  within  the  NATO  M&S  enterprise  are  at  least  evidently 
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interpretable  among  stakeholders,  and  preferably  interoperable  (to  within  similarity  of  mission-  and 
simulation-space  referents)  across  the  enterprise.  While  complete  interoperability  and  exhaustive 
re -usability  are  not  likely  to  occur  even  under  the  most  auspicious  circumstances,  and  while  it  is 
certain  that  no  degree  of  product  ‘best-practice’  results  could  guarantee  such  consistency;  any  element 
of  the  prescribed  practice  that  can  be  established  with  a  view  to  improving  product  consistency  should 
be  adopted. 

•  Product  Quality  -  Conceptual  model  product  quality  across  the  enterprise  is  relevant  from  two 
complimentary  perspectives.  On  the  one  hand,  consistent  quality  resulting  from  the  subject  guidance 
is  directly  correlated  to  the  value  of  the  return  on  investment  in  conceptual  modeling  itself.  On  the 
other  hand,  sufficient  and  auditably  documented  product  quality  across  conceptual  models  will 
influence  greatly  both  the  likelihood  of  use  of  the  conceptual  modeling  best-practice  guidance  and  the 
re-use,  sharing,  and  recovery  of  utility  of  the  pursuant  models  themselves. 

4.2.4  Consequences  of  Conceptual  Modeling  for  Enterprise  Mission 

The  use  of  simulation  in  military  applications  such  as  analysis,  acquisition,  training  and  decision  support 
requires  that  the  simulations  are  fit  for  use.  V&V  can  be  applied  to  evaluate  if  this  fitness  for  use  is  achieved. 
The  quality  of  the  end-product  (i.e.,  the  simulation)  is,  however,  largely  dependent  on  the  quality  of  the 
intermediate  products.  To  be  more  specific,  a  large  portion  of  the  problems  with  the  end-product  come  from  a 
poor  understanding  of  the  customer’s  situation  which  leads  to  a  low  quality  of  the  requirements.  Explicitly 
building  a  conceptual  model  is  one  of  the  ways  to  improve  the  quality  of  the  end-product  by  allowing  for  a 
good  starting  point  for  its  development.  In  order  for  the  conceptual  model  to  be  able  to  really  improve  the 
overall  quality,  the  quality  of  the  conceptual  model  itself  must  be  sufficiently  high.  Building  the  conceptual 
model  is  the  step  in  simulation  development  in  which  the  actual  modeling  takes  place.  Therefore  validation 
(determining  whether  the  abstractions  taken  during  the  modeling  are  allowed)  of  the  conceptual  model  against 
the  stakeholders’  purpose  is  important  for  the  simulation’s  fitness  for  purpose. 

From  a  project  management  point  of  view,  the  conceptual  model  is  the  last  step  in  simulation  development 
where  correcting  errors,  such  as  having  erroneously  left  out  important  parts  that  should  be  represented  in  the 
end-product,  is  still  relatively  easy,  quick  and  cheap.  If  simulation  design  and  implementation  starts,  correcting 
mistakes  quickly  becomes  much  more  costly.  Therefore  V&V  of  the  conceptual  model  is  an  important  form  of 
risk  mitigation. 

The  amount  of  resources  put  into  the  V&V  effort  must  be  related  to  the  risk  (financial  risk,  loss  of  lives,  etc.) 
of  using  a  faulty  end-product  because  a  faulty  conceptual  model  was  used  for  its  development.  If  almost  no 
consequences  exist  of  using  a  faulty  conceptual  model  then  the  V&V  effort  may  be  low.  If,  however, 
a  substantial  risk  is  present,  and  using  M&S  results  for  military  application  usually  has,  the  V&V  effort  must 
be  accordingly. 

For  an  enterprise  it  is  advantageous  to  re-use  as  much  of  previous  efforts  as  possible.  This  means  that 
conceptual  models  from  previous  projects  should  be  available  for  re-use,  but  it  also  means  that  V&V  results 
should  be  available.  One  important  way  of  achieving  this  is  to  use  a  set  of  enterprise-mandated  processes  and 
product  formats.  Then  a  common  approach  across  projects  can  be  achieved.  On  enterprise  level,  a  V&V 
methodology  must  be  chosen  that  supports  this  reuse  in  the  sense  that  the  V&V  data  of  previous  efforts  should 
be  (partially)  re-usable. 
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4.3  CONCEPTUAL  MODELING  ENTERPRISE  STAKEHOLDERS 

Stakeholders  can  be  defined  as  people  being  affected  by  a  process  or  product.  In  this  sense  conceptual  modeling 
and  conceptual  models  have  a  number  of  stakeholders  -  each  with  different  responsibilities,  concerns  and 
interests.  They  will  typically  also  have  different  backgrounds  and  consequentially  different  perspectives, 
and  therefore  often  use  different  “languages”  or  terminology. 

4.3.1  The  Importance  of  Identifying  Stakeholders 

Explicit  identification  of  stakeholders  of  the  conceptual  modeling  endeavor  will  help  each  stakeholder 
understand  his  role  in  a  larger  context.  It  will  make  him  aware  of  the  roles  of  other  stakeholders  and  thus 
facilitating  necessary  communication  between  stakeholders. 

4.3.2  Main  Categories  of  Stakeholders 

The  primary  stakeholder  targeted  by  this  guidance  is  the  developer  of  conceptual  models.  There  are  however 
several  other  types  of  stakeholders.  These  can  be  referred  to  by  many  names.  For  our  purpose  we  will  use  the 
following  main  categories: 

•  Sponsor:  This  is  a  person  or  organization  that  sees  a  need  for  modeling  and  simulation  in  the  solving 
of  a  problem  such  as  specifying  an  operational  requirement  or  analyzing  a  capability.  The  sponsor 
will  typically  initiate  and  fund  a  modeling  and  simulation  activity. 

•  Producer:  This  is  a  person  or  organization  that  will  endeavor  to  satisfy  the  sponsor’s  need. 
The  supplier  will  undertake  activities  such  as  project  management  and  development  of  the  conceptual 
model.  This  will  typically  include  subject-matter  experts  providing  mission  space  knowledge  and 
knowledge  engineers  eliciting,  structuring  and  documenting  knowledge. 

•  Consumer:  This  is  a  person  or  organization  that  will  put  the  conceptual  model  to  use  in  order  to 
implement  an  executable  model  to  satisfy  the  sponsor’s  needs.  The  users  of  the  simulation  model  may 
also  be  conceptual  model  consumers,  as  they  will  profit  from  understanding  mission  domain  concepts 
and  their  relationships. 

In  an  organization  where  conceptual  model  development  is  a  recurring  activity,  it  will,  in  the  long  run, 
pay  to  employ  a  repository  containing  results  from  past  development  efforts.  In  this  approach  is  chosen,  there 
will  be  need  for  a: 

•  Custodian:  This  is  the  person  or  organization  that  ensures  that  the  repository  is  maintained  and  policies 
adhered  to. 

In  order  to  ensure  the  quality  of  the  conceptual  model,  it  is  recommended  to  implement  a  verification  and 
validation  process.  This  will  be  carried  out  by  an: 

•  Evaluator:  The  person/organization  that  validates  the  conceptual  models. 

4.3.3  Use  Case  Description  of  a  Conceptual  Model  Development  Process 

Figure  4-3  shows  a  high  level  view  of  the  activities  and  stakeholders  typically  involved  during  a  conceptual 
model  development  process. 
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Dev  elopment  Use  Cases 


Set  strategic  objectives  and  capability  needs 
Define  mission/scenario  to  be  analysed 


1  .  Create  or  review  relevant  scenarios 

2.  Reach  consensuson  problem  formulation, 
objectives  of  the  simulation  study 

3.  Produce  a  Need  Statement 

4.  Specify  available  resources,  e.g.  man-years, 
budget,  tim  e 


1  .  Identify  the  stakeholders 

2.  Define  th  e  i  r  i  n  te  re  sts/co  n  ce  rn  s 

3.  Describe  their  involvement  in  the  project 

4.  Inform  the  stakeholders  of  their  roles  and 
authorities 


1  .  Secure  necessary  resources 

2  .  Assig  n  p roject  tea  m  roles 

3.  Establish  an  M&S  project  plan  (WBS,  resource 
allocation,  schedule) 

4.  Establish  CM  and  other  policies 


1.  Elicite  requirements 

2.  Analyze  requirements 

3.  Document  requirements 

4.  Derive  knowledge  needs 


1  .  Identify  authoritative  sources  of  n 
kn  o  w  I  e  d  g  e 

2.  Gather  Knowledge 

3.  Structure  knowledge 

4.  Document  Knowledge 


1.  Decide  on  the  conceptual  prim  itives  and 
model  kinds  that  can  represent  the  knowledge 
gathered 

2.  Select  Formalism(s),  viewsand  notation  to 
support  the  CM  documentation 


1.  Search  forexisting  CM  com  ponents  with 
domain  overlap 

2.  Integrate  CM -com  ponents  into  a  coherent 
overall  CM 


1.  Populate  CM  design  with  gathered  knowledge 
2  .  Docum  ent  CM 

3.  Submit  new  CM  to  CM  repository 


1  .  P  ro  vide  re  po  si  to  ry  se  rv  ices  (search  ,  retrieve , 
store,  purge,  update) 

2  .  M  a  in  ta  in  re  posito  ry  co  n  te  nt  (cata  log  u  e , 
configure) 

3.  Integrate  new  knowledge  into  military  domain 
ontology 


1.  Use  CM  for  understanding  the 
mission/scenario  to  be  analyzed 

2.  Use  CM  for  specifying  detailed  requirements 
for  executable  models 

3.  Use  CM  forguidance  in  developing 
executable  m  odels  or  training  systems 


1.  Establish  validation  procedures  and  criteria 

2.  Review  and  evaluate  CMs 

3.  Approve  additionsto  CM  repository 


1.  Officialize  the  CM  as  satisfying  the  need 
state m  ent 


3 


Figure  4-3:  High  Level  Use  Case  Diagram  Illustrating  the  Main  Actors 
and  Interactions  During  a  Conceptual  Model  Development  Process. 


4.3.4  Stakeholders  Responsibilities 

Some  of  the  main  concerns  of  the  different  stakeholders  in  the  process  of  conceptual  model  development  and 
use  are  summarized  in  Table  4-1. 
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Table  4-1:  Stakeholders’  Concerns. 

Stakeholder 

Responsibility 

Sponsor 

•  Analysis  of  combat  outcome,  system  performance,  system  alternative 
trade-offs,  etc. 

•  Cost-effective  training. 

•  Credibility  of  analysis  results. 

•  Making  sure  the  conceptual  model  represents  necessary  and  sufficient 
relevant  information  about  operational  issues  and  mission  context  of 
interest  (correct  scope). 

•  Decision-making  based  on  analysis  products  (introducing  a  new 
tactic,  procuring  a  new  system,  etc.). 

•  Cost  of  modeling  and  simulation. 

Producer 

(M&S  Project  Manager) 

•  Effective  use  of  allocated  resources  (e.g.,  ensuring  reuse  when 
appropriate). 

•  Unambiguous  communication  with  customer. 

Producer 

(Knowledge  Engineer) 

•  Understanding  of  operational  issues  and  mission  context. 

•  Translation  of  operational  issues  and  mission  context  into  a 
conceptual  model. 

•  Unambiguous  communication  with  SMEs  and  implementers. 

Producer 

(M&S  Subject-Matter  Expert, 
Military  Subject-Matter 

Expert) 

•  Understanding  operational  issues  and  mission  context. 

•  Provide  technical  and  military  know-how  at  appropriate  level 
of  detail. 

Consumer 

(Model  Implementer) 

•  Understanding  operational  issues  and  mission  context. 

•  Implementation  of  simulation  model. 

•  Verification  of  simulation  model  compliance  with 
conceptual  model. 

Consumer 

(Analyst) 

•  Understanding  operational  issues  and  mission  context. 

•  Producing  relevant  analysis  products. 

Consumer 

(Training  System  Developer) 

•  Understanding  operational  issues  and  mission  context. 

•  Producing  adequate  training  environment. 

Custodian 

•  Provide  services  for  effective  reuse  of  available  knowledge  and 
conceptual  model  components. 

Evaluator 

•  Ensuring  validity  of  conceptual  model  and  compliance  with 
requirements. 

RTO-TR-MSG-058 


4-9 


INTRODUCTION  TO  CONCEPTUAL 
MODELING:  BEST-PRACTICE  GUIDANCE 


ORGANIZATION 


4.4  CONCEPTUAL  MODEL  ATTRIBUTES  AND  DEFINITIONS 

Conceptual  modeling  has  often  been  practiced  as  an  art  form  or  implied  activity  in  M&S  development  processes. 
There  was  has  been  little  formal  structure  or  definition,  and  no  consistent  approach  to  applying  various  standards 
or  formalism  in  previous  practice.  Conceptual  modeling  has  been  defined  in  several  ways  in  literature,  of  which 
copious  evidence  is  provided  in  Annex  K  -  Bibliography.  Most  of  these  definitions  are  compatible,  overlapping, 
or  complimentary,  but  taken  as  a  whole;  they  produce  considerable  ambiguity  in  regards  to  the  scope  of  the 
conceptual  modeling  process  and  products.  Further,  consideration  of  conceptual  modeling  in  the  Military  M&S 
context  puts  additional  constraints  and  implications  on  the  set  of  applicable  definitions. 

4.4.1  Scoping  Definitions 

Since  it  is  difficult  to  write  a  definition  of  conceptual  modeling  that  is  not  self-referential,  and  while  Annex  J 
-  Lexicon  provided  a  glossary  of  relevant  terms;  the  following  definitions  will  be  used  for  the  purposes  of  this 
guidance  document: 

•  A  referent  is  a  set  of  fictive  or  existing  systems,  entities,  phenomena,  or  processes  subjected  to  modeling 
and  simulation,  which  a  user  may  want  to  consider  in  the  context  of  their  own  objectives  or  interest. 

•  A  model  is  a  simplified/abstracted  representation  of  a  part  of  reality  or  a  potential  reality.  It  is  a  physical, 
mathematical,  or  otherwise  logical  representation  of  a  referent  of  interest. 

•  A  simulation  is  the  implementation  of  a  model  over  time. 

•  A  concept  is  an  abstract  idea  or  a  mental  symbol,  typically  associated  with  a  corresponding  representation 
in  language  or  symbology,  that  denotes  all  of  the  objects  in  a  given  category  or  class  of  entities, 
interactions,  phenomena,  or  relationships  between  them. 

•  A  conceptual  model  is  a  model  that  abstractly  represents  a  referent. 

•  An  M&S  conceptual  model  is  a  conceptual  model  intended  for  realizing  a  simulation  capability. 

•  A  military  M&S  conceptual  model  is  an  M&S  conceptual  model  within  the  military  domain. 

The  relationship  between  these  terms  is  further  illustrated  in  Table  4-2. 


4-10 


RTO-TR-MSG-058 


dMNATO 
WP  I  OTAN 


INTRODUCTION  TO  CONCEPTUAL 
MODELING:  BEST-PRACTICE  GUIDANCE 


Table  4-2:  Relationships  Between  Defined  Terms. 


Term 

Definition 

Subject 

Attribute 

Relationship 

Object 

Concept 

Abstraction 

Generalized 

Characterizes 

Referent 

Model 

Description 

Simplified 

Explicit 

Represents 

Referent 

Conceptual  Model 

Model 

Abstract 

Represents 

Referent 

Military  Conceptual 
Model 

Conceptual 

Model 

Represents 

Military 

Referent 

Simulation 
Conceptual  Model 

Conceptual 

Model 

Represents 
Referent  in 

Simulation 

Military-simulation 
Conceptual  Model 

Conceptual 

Model 

Represents 
Military 
Referent  in 

Simulation 

These  basic  terms  define  the  content  of  the  conceptual  model,  which  is  the  set  of  information  that  is  the 
collection  of  abstractions  of  the  represented  referents.  But  it  is  also  necessary  to  consider  the  nature  of  the 
conceptual  model  in  terms  of  the  characteristics,  the  composition,  and  the  context  of  the  conceptual  model  in 
the  relationship  of  the  Conceptual  Model  Space  to  the  Mission  Space  and  Simulation  Space  must  be  defined. 

4.4.2  Conceptual  Model  Characteristics 

Any  conceptual  model  will  have  characteristics  of  the  following  categories:  Quality  Characteristics,  Utility 
Characteristics,  Formality  Characteristics,  and  Abstractness  Characteristics.  Figure  4-4  provides  an  illustrative 
list  of  characteristics  in  these  categories,  but  is  not  intended  to  be  exhaustive  in  its  illustration. 


RTO-TR-MSG-058 


4-11 


INTRODUCTION  TO  CONCEPTUAL 
MODELING:  BEST-PRACTICE  GUIDANCE 


r  Class  CM  Characteristics  (grouped) 


Figure  4-4:  Conceptual  Model  Characteristics. 


A  practical  set  of  definitions  for  these  illustrative  characteristics  may  be  found  in  the  Lexicon  to  this  document. 
Definitions  of  the  four  categories  are  as  follows: 

•  Quality  is  a  totality  of  features  and  characteristics  of  a  conceptual  model  that  bear  on  its  ability  to 
satisfy  stated  or  implied  needs.  It  measures  how  “good”  a  conceptual  model  might  be  for  various 
purposes. 

•  Utility  is  the  property  of  the  relative  satisfaction  gained  by  the  use  of  a  system  expressed  in  terms  of  a 
value  and  cost.  It  measures  the  kinds  of  purposes  for  which  the  conceptual  model  might  provide 
value. 

•  Formality  is  compliance  with  formal  or  conventional  rules. 

•  Abstractness  relates  to  the  way  the  conceptual  model  abstracts  or  symbolizes  the  referent. 

These  characteristics  are  inherent  to  the  conceptual  model,  and  are  not  necessarily  explicitly  defined,  measured, 
or  in  some  cases  even  known.  But  it  is  this  set  of  characteristics  that  will  determine  the  use  of  the  conceptual 
model  by  the  Stakeholders,  the  re-use  of  the  conceptual  model  by  future  Stakeholders,  and  the  V&V  Status 
throughout  the  conceptual  model  development  and  life  cycle. 
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4.4.3  Conceptual  Model 

Most  importantly,  the  conceptual  model  has  content.  And  this  content  is  composed,  structured,  and  viewed  as 
shown  in  Figure  4-5.  This  figure  shows  that  a  conceptual  model  is  composed  of  Model  Kinds,  which  are 
similarly  composed  of  Conceptual  Primitives.  Model  kinds  use  Formalism,  and  Conceptual  Primitives  are 
specified  by  that  Formalism.  Notation  supports  the  Formalism  and  realizes  Views,  and  the  Views  allow  the 
conceptual  model  to  be  presented  in  appropriate  manners  to  respective  Stakeholders. 


CM  Meta- Meta  Model 


Conceptual  Model 


Uses 


T 


Realizes 


Notation 

r  £ 
Formalism 

s _ J 

s _ 4 

Supports'" 

Is  specified  by 


k 

j 

i 

i 

r  t 

Conceptual  Primitive 

^ _ 

j 

Figure  4-5:  Conceptual  Model  Composition. 

These  composition  terms  have  standard  definitions,  per  Webster: 

•  Primitive  -  “an  elemental  component  from  which  higher-order  composites  may  be  composed. 
Commonly  applied  to  conceptual  model  constructs”. 

•  Model  Kind  -  “a  type  or  alternative  classes  of  models”. 

•  Formalism  -  “the  practice  or  the  doctrine  of  strict  adherence  to  prescribed  or  external  forms”. 

•  Notation  -  “a  system  of  characters,  symbols,  or  abbreviated  expressions  used  in  an  art  or  science  or  in 
mathematics  or  logic  to  express  technical  facts  or  quantities”. 

•  View  -  Explication  of  a  subject  model-kind  instance  created  using  one  or  another  selected  notation. 

The  following  are  illustrative  lists  of  these  composition  elements.  These  lists  are  not  intended  to  be  exhaustive 
in  their  illustration. 

•  Example  Primitives:  Entity,  object,  signal,  time,  event,  attribute,  message,  state,  etc. 

•  Example  Model  Kinds:  Dynamic,  static,  state  machine,  structural,  behavioral,  agent,  object-based, 
process-based,  Meta  data,  entity  relation,  activity,  composition,  generalization,  collaboration,  event 
trace,  sequence,  etc. 

•  Example  Formalisms  and  Suitable  Notations:  Unified  Modeling  Language  (UML),  Conceptual  Modeling 
Language  (CML),  System  Modeling  Language  (SysML),  Integration  Definition  for  Function  Modeling 
(IDEFO),  Base  Object  Models  (BOM),  BOM++,  Conceptual  Graphs,  Mind  Maps,  and  Business  Process 
Modeling  Notation  (BPMN). 

•  Example  Views:  Class  diagram,  activity  diagram,  swim  lanes,  state  diagram,  operational  view,  etc. 
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A  more  detailed  discussion  of  the  composition  of  the  conceptual  model,  in  terms  of  the  design  process,  will  be 
given  in  Chapter  6. 


4.5  CONCEPTUAL  MODEL  PERSPECTIVES  AND  COMPOSITION 

Conceptual  Model  of  a  Simulation  is  predicated  for  the  purposes  of  this  effort  as  the  conceptual  model  of  the 
Mission  Space  (i.e.,  that  which  is  represented  within  the  simulation  during  its  execution)  integrated  with  the 
conceptual  model  of  Simulation  Space  (i.e.,  encompassing  the  design  and  implementation  of  the  simulation 
artefact  itself).  Consequently,  it  is  important  to  differentiate  between  aspects  of  the  conceptual  model  space, 
the  Mission  Space  of  the  referent  world,  and  the  Simulation  Space  where  the  simulation  itself  resides.  Each  of 
these  Spaces  will  impact  the  design  of  the  conceptual  model  in  its  own  fashion. 

Figure  4-6  shows  the  nature  of  these  three  spaces,  and  how  they  interact  through  the  requirements  and  design 
of  the  conceptual  model.  Following  are  examples  of  requirements  which  might  be  applied  to  the  conceptual 
model  components  relevant  to  the  two  spaces  and  the  composite  conceptual  model  itself. 

•  Example  from  conceptual  model  composite  space:  The  conceptual  model  shall  be  machine-readable. 

•  Example  from  Mission  Space:  The  conceptual  model  shall  represent  World  War  II  trench  warfare. 

•  Example  from  Simulation  (Implementation)  Space:  The  conceptual  model  shall  be  at  a  level  of 
abstraction  allowing  real-time  execution  at  1000  Hz  on  a  commercial  desktop  platform. 


CM 

Needs 


CM 

Policies 


CM 

Design 


CM  SPACE 


CM 

Constraints 


CM 

Requirements 


CM 

Stakeholders 


CM 

Knowledge 


Sim 

Stakeholders 


Sim 

Needs 


Sim 

Constraints 


Sim 

Design 


Sim 

Docs 


Simulation 


Sim 

Knowledge 


Sim 

Rqmts 


Sim 

Policies 


Figure  4-6:  Mission  Space  and  Simulation  Implementation  Spaces  Indicated  as  Disjoint,  but  Highly 
Integrated  ‘Worlds’  Whose  Natures  are  to  be  Included  in  the  Entire  M&S  Conceptual  Model. 
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Also  see  Annex  I  -  Conceptual  Model  Examples. 

The  diagrams  of  Figure  4-6  and  Figure  4-7  illustrate  the  notions  of  the  disjoint  representation  and  simulation 
implementation  spaces  and  their  composition  into  the  fully  articulated  conceptual  model  artefact. 


Figure  4-7:  Simple  Indication  of  Composition  of  the  Simulation  Conceptual  Model 
from  Mission  Space  and  Simulation  Implementation  Space  Components. 


Typically,  the  conceptual  model  is  thought  to  only  represent  the  Mission  Space.  Although  it  is  often  said  that 
the  ideal  conceptual  model  is  “implementation  independent”,  thus  “Simulation  Space  independent”,  such  is 
rarely  ever  the  case.  Even  if  the  conceptual  model  does  not  explicitly  mention  an  implementation,  and  may  be 
highly  portable  from  one  Simulation  Space  to  the  next,  the  original  Simulation  Space  to  which  the  conceptual 
model  was  designed  will  have  influenced  the  structure  and  content  of  the  conceptual  model,  sometimes  in 
significant  ways.  This  is  also  true  of  the  Conceptual  Model  Space  influences,  such  as  Conceptual  Model 
Stakeholders  and  Policies. 

It  is,  in  fact,  the  frequency  of  conflation  of  mission  and  simulation  implementation  spaces,  and  the  occurrence 
of  unanticipated  pejorative  consequences  that  has  motivated  the  Task  Group  to  adopt  this  particular  partition 
convention.  By  making  the  partition  explicit,  the  degree  of  machine  independence  and  the  artificial 
implementation  of  mission  space  representations  by  means  of  undesirably  static  implementation  techniques 
are  believed  to  be  better  appreciated  and  controlled. 


4.6  BEST-PRACTICE  SPECIFICATION  NOTATION 

One  of  the  practical  determinations  and  findings  of  the  Task  Group  related  to  representational  notations 
whereby  specifications  of  best-practice  and  resulting  conceptual  models  could  be  mad  manifest;  and,  whereby 
the  conceptual  model  itself  may  be  captured,  published,  archived,  retrieved,  understood,  modified, 
and  maintained  in  a  systematic  and  deliberate  manner  without  corrupting  the  semantic  content  of  the  model 
itself.  It  was  abundantly  clear  from  the  Team’s  investigations  of  current  practice  and  available  standards  that 
myriad  notational  schema  were  available.  It  was  further  determined  by  the  Group  that  the  use  of  any  of  any 
one  notational  form  in  expressing  best-practice  or  the  requirement  for  use  of  any  such  single  form  by 
conceptual  model  practitioners  in  executing  the  recommended  best-practice  would  be  found  to  be  technically 
and  socially  impractical,  however  desirable  and  fit-for-purpose  it  might  seem. 
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Notwithstanding  this  determination,  it  was  clear  that  the  Team  needed  a  provisional  or  ‘nominal’  notation  for 
expressing  its  guidance;  and  that  the  conceptual  modeling  practitioner  would  be  obliged  to  select  some  one 
specific  documentary  notational  schema  in  executing  the  recommended  best-practice.  In  the  later  case, 
the  Group  resolved  that  practitioners  should  (could)  elect  any  formulation  consistent  with  the  representational 
capacity  required  to  express  their  particular  conceptual  model  and  commensurate  with  the  norms  and 
requirements  of  the  enterprise  environment  in  which  they  worked.  Naturally,  selection  from  among  common 
standard  notations  and  specification  languages  is  strongly  recommended  in  any  case.  In  the  former  case, 
the  Group  was  particularly  sensitive  to  its  own  use  of  notational  artifice  for  two  reasons.  On  the  one  hand,  any 
notation  employed  herein  to  specify  conceptual  modeling  process  or  conceptual  model  structure  and  semantic 
content  must  be  sufficiently  expressive  and  ecumenical  so  that  the  best-practice  guidance  communicated 
thereby  might  be  clearly  intelligible.  On  the  other  hand,  the  Group  was  anxious  not  to  imply  by  its  own 
selection  and  use  of  notational  schema,  that  our  particular  choice  of  schema  was  particularly  preferred  for  use 
by  practitioners  -  let  alone  a  required  element  of  the  recommended  best-practice. 

Therefore,  the  group  strove  to  use  the  most  simple  and  self-evident  notation  within  the  document,  and  to 
reserve  the  best-practice  guidance  itself  to  vernacular  English  in  Chapters  5  and  6  and  in  tabular  prescription 
in  annexes  tabular  prescriptive  guidance  in  Annexes  G  and  H  for  process  and  product  respectively. 
The  fundamental  activity-on-node  with  control-on-arrow  notation  with  which  this  guidance  is  modestly 
introduced  in  Chapter  6  for  process  particularly  together  with  an  expression  of  the  degree  to  which  this 
notational  convention  is  practically  a  ‘least  common  denominator’  of  several  common  representational  forms, 
is  indicated  in  the  figures  following. 

Figure  4-8  illustrates  the  simplified  baseline  graphical  representation  for  indication  of  activities  and  their 
relationships  with  other  entities  in  the  conceptual  modeling  practice  process  Used  by  the  Task  Group  in 
following  explication. 


Data  Store  1 


Data  Store  2 


▲ -  - A 


Figure  4-8:  Simplified  Process  Graphical  Notation  Used  in 
Expressing  Conceptual  Modeling  Best-Practice  Process. 


Figure  4-9  indicates  alternative  canonical  views  with  information-preserving  transform  operations  are 
possible,  facilitating  use  of  CASE-supported  native  representations  and  guaranteed  information  sharing. 
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Figure  4-9:  Notional  Illustration  of  Relationship  of  Simplified  Process  Specification 
Graphical  Notation  in  Context  of  Other  Canonical  and  More  Powerful  Notations. 


4.7  CONCEPTUAL  MODEL  QUALITY  (VERIFICATION  AND  VALIDATION) 

In  this  section  some  aspects  that  are  relevant  for  understanding  the  role  of  V&V  of  a  conceptual  model  in  the 
project  context  are  described.  Although  the  complete  product  life  cycle  is  not  described  in  this  report,  some 
aspects  of  this  larger  setting  may  still  be  useful  for  a  complete  understanding.  An  enterprise  that  decides  to 
explicitly  make  a  conceptual  model  clearly  has  the  desire  to  deliver  quality  products.  Just  making  a  conceptual 
model,  however,  is  not  sufficient  for  achieving  quality.  The  quality  of  the  conceptual  model  (and  other 
intermediate  products)  must  be  sufficient  to  allow  the  development  of  a  quality  end-product.  V&V  helps  in 
determining  the  quality  of  the  final  product  and  must  be  applied  throughout  the  whole  of  the  development, 
and  thus  also  to  the  conceptual  model.  V&V  of  the  whole  development  can  be  a  large  undertaking.  Here  we 
describe  the  V&V  work  with  the  focus  on  conceptual  model  and  as  if  the  rest  of  the  V&V  work  is  non¬ 
existent.  It  is  important,  however,  to  understand  that  the  result  of  V&V  of  a  conceptual  model  is  only  a  part  of 
the  overall  V&V  effort. 
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4.7.1  Context  of  Conceptual  Model  V&V  Effort 

The  V&V  work  consists  of  a  number  of  activities  that  are  described  in  the  activities  in  this  guidance.  These 
V&V  activities  do  not  all  need  to  be  completely  finished  before  a  next  activity  can  be  started:  they  may  partly 
be  executed  in  parallel.  Process  Activities  can  also  be  executed  iteratively. 

The  V&V  work  starts  with  agreement  on  a  number  of  elements  such  as:  who  performs  the  V&V  work,  what 
resources  (time,  money,  etc.)  are  available  for  V&V,  and  how  the  results  of  the  V&V  work  are  used.  See  also 
the  V&V  elements  in  the  “Meta  data”  product  in  the  V&V  elements  in  the  “Information  Pool”  of  Annex  H, 
Table  H-5.  The  amount  of  available  resources  for  V&V  must  be  related  to  the  risk  (financial,  loss  of  lives, 
etc.)  of  using  a  faulty  end-product  because  a  faulty  conceptual  model  was  used  for  its  development.  If  almost 
no  consequences  exist  of  using  a  faulty  conceptual  model,  then  the  V&V  effort  may  be  low.  If,  however,  a 
substantial  risk  is  present,  and  using  M&S  results  for  military  application  usually  has,  the  V&V  effort  must  be 
accordingly.  The  applied  V&V  methodology  should  be  tailorable  such  that  it  delivers  the  best  possible  V&V 
given  the  risk  and  available  resources. 

4.7.2  Quality  Attributes  Relevant  to  Conceptual  Model  V&V 

Three  properties  must  be  shown  during  the  V&V  work:  utility,  validity  and  correctness: 

•  Utility 

•  Assesses  the  effectiveness  and  efficiency  of  the  conceptual  model  in  solving  the  problem  statement. 
Evaluation  metrics  for  utility  comprises  three  areas:  value  or  benefits  (measures  of  effectiveness, 
measures  of  performance,  etc.),  costs  (money,  time,  etc.)  and  use  risks  (impact,  probability,  etc.). 

•  Validity 

•  Assesses  the  level  of  agreement  of  the  conceptual  model  behavioral  representation  with  that  of  the 
simuland.  Validity  metrics  are  also  used  to  assess  the  consequences  any  behavioral  discrepancies 
on  the  utility  of  the  M&S  system. 

•  Correctness 

•  Assesses  whether  the  conceptual  model  implementation  is  free  of  error  and  of  sufficient  precision. 
Correctness  metrics  are  also  used  to  assess  the  consequences  of  implementation  discrepancies  on 
both  the  validity  and  utility  of  the  conceptual  model. 

4.7.3  Sufficiency  Criteria  for  Conceptual  Model  V&V 

In  order  for  the  conceptual  model  to  have  utility  it  must  help  improve  the  quality  of  the  end-product  within 
with  resources  that  are  in  balance  with  the  risk.  Building  the  conceptual  model  is  the  step  in  simulation 
development  in  which  the  actual  Modeling  takes  place.  Therefore  validation  (determining  whether  the 
abstractions  taken  during  the  Modeling  are  allowed)  of  the  conceptual  model  against  the  stakeholders’  purpose 
is  important  for  the  simulation’s  fitness  for  purpose.  In  order  to  serve  its  purpose  the  constructed  conceptual 
model  must  also  be  correctly  implemented  such  that  its  representation  is  useful  and  leads  to  a  correct 
transformation  of  purpose,  via  requirements  to  design  and  implementation. 

A  conceptual  model  that  has  been  V&V-ed  with  positive  results  increases  the  chances  of  a  high  quality  end- 
product  and  can  serve  as  part  of  a  referent  for  the  V&V  of  that  final  product.  For  conceptual  models  no  formal 
acceptance  process  (accreditation)  is  available,  it  must  however  be  acceptable  for  the  stakeholders  (users, 
developers,  etc.)  that  use  the  conceptual  model  in  the  development  process.  This  must  be  achieved  in  two 
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ways.  First,  the  acceptance  criteria  must  be  derived  from  the  stakeholders’  purpose,  and,  second,  the  format  in 
which  the  results  of  the  V&V  effort  are  delivered  must  be  suited  for  their  purpose. 

4.7.4  V&V  Compliance  Framework 

It  is  important  that  the  V&V  effort  results  in  a  compliance  network  linking  stakeholders’  goals  via  a  set  of 
evidences  to  justifiable  claims. 


Figure  4-10:  The  V&V  Argumentation  Framework  (AF)  Consists 
of  the  Goal  Network,  Evidence  and  the  Claim  Network. 


The  goal  network  is  used  in  a  top  down  fashion  for  reasoning  about  the  decomposition  of  a  top-level  objective 
into  smaller  goals  and,  finally,  into  a  set  of  definitions  of  tests  to  generate  evidence.  Therefore  goal  networks 
can  be  used  for  planning  purposes.  V&V  goal  networks  are  closely  related  to  and  overlap  with  goal-oriented 
requirements  engineering. 

Claim  network  structures  work  in  the  opposite  way.  A  claim  network  structure  aggregates  evidence  collected 
in  a  certain  context  into  sub-claims,  and  these  sub-claims  into  a  single  justified  top-level  claim  on  the  subject 
of  interested.  This  aggregation  is  done  by  means  of  logical  arguments. 

The  rationale  for  using  both  a  goal  network  and  a  claim  network  stems  from  the  fact  that  in  practice 
decomposition  and  re-composition  do  not  mirror  each  other  for  various  practical  reasons  like  time,  cost  and 
availability  of  equipment  to  gather  the  appropriate  evidence. 

After  completion  of  the  claim  network,  and  thus  also  the  goal  network  and  evidence  collection,  the  results 
must  be  communicated  to  the  stakeholders.  The  results  are  an  acceptance  recommendation  in  the  format  best 
suited  for  the  stakeholders’  purpose  with  the  V&V  results.  Since  there  is  no  formal  acceptance  process  for 
conceptual  models,  the  result  is  not  an  accredited  conceptual  model  but  a  recommendation  on  acceptance. 

If  all  is  well  the  top  claim  shows  that  the  top  goal  is  justified.  For  all  M&S  related  products,  and  indeed 
possibly  all  products,  the  top  goal  is  of  the  same  form:  the  system  must  provide  utility  for  the  given  purpose. 
Therefore  the  top  goal  of  the  Goal  Network  is  a  utility  goal.  In  case  of  conceptual  models  the  following  top 
goal  is  proposed: 

The  Conceptual  Model  provides  utility  for  the  improvement  of  the  quality  of  the  end-product. 

This  top  goal  must  be  decomposed  into  smaller  goals.  At  first  these  are  likely  to  be  more  specific  utility  goals. 
At  some  point  the  utility  goals  can  be  expressed  either  into  criteria  for  which  tests  can  be  devised  or  into 
smaller  goals  that  deal  with  validity  and  correctness.  The  validity  goals  express  criteria  on  the  abstractions 
from  reality  that  are  made  in  the  conceptual  model  since  the  phase  in  which  the  conceptual  model  is  build  is 


RTO-TR-MSG-058 


4-19 


INTRODUCTION  TO  CONCEPTUAL 
MODELING:  BEST-PRACTICE  GUIDANCE 


the  modeling  phase.  Only  those  abstractions  are  allowed  that  will  result  in  a  model  that  -  given  its  purpose 
and  the  way  it  is  used  in  the  final  product  -  result  in  a  behaviour  that  is  indistinguishable  from  the  equivalent 
behaviour  in  the  real  world.  The  correctness  goals  state  criteria  on  how  the  conceptual  model  is  build, 
expressed  in  formalism  and  used  in  the  rest  of  the  development  process.  The  conceptual  model  must  for 
example  be  understandable  for  all  relevant  stakeholders  and  be  specified  without  errors  in  formalisms  that  are 
appropriate. 

Some  of  these  criteria  will  be  independent  of  the  specific  topic  and  formalisms,  but  many  criteria, 
and  especially  those  in  the  validity  goals,  will  be  highly  dependent  on  the  stakeholder’s  purpose  with  the  final 
product.  Inspiration  for  criteria  can  be  found  in  standards  on  software  quality,  namely  [ISO/IEC  9126],  papers 
on  conceptual  model  quality  such  as  [Lindland]  [Pace]  [Teeuw],  SMEs  and  domain  specific  knowledge  that 
may  be  available  from  previous  quality  evaluation  efforts.  A  good  overview  of  quality  frameworks  specific 
for  conceptual  models  is  given  by  [Moody]. 
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Establishment  and  implementation  of  best-practices  are  critical  to  ensure  that  a  sound  and  structured  process  is 
followed  to  produce  conceptual  models  of  sufficient  quality,  and  to  ensure  that  conceptual  model  products  are 
robust  and  complete.  It  is  particularly  important  to  establish  a  homogeneous  and  common  process  for  conceptual 
model  development  to  enable  a  structured  approach  and  to  build  a  common  vocabulary  across  the  M&S 
community  for  the  sake  of  collaboration  and  reuse. 

Based  on  the  research  effort  described  above,  and  in  order  to  meet  the  stated  objectives  of  advancing  the 
development  of  conceptual  models  beyond  current  practice,  Chapters  5  and  6  (along  with  corresponding 
annexes)  constitutes  NATO  Best-Practice  Guidance,  provided  to  enable  the  development  of  quality  and 
re-useable  conceptual  models  of  military  models  and  simulations. 

5.1  PROCESS  GUIDANCE  INTRODUCTION 

This  chapter  provides  the  MSG-058  Task  Group’s  “Best-Practice  Guidance  Specification  (BPGS)”  for  the 
“Conceptual  Model  Best-Practice  Development  Process”  as  indicated  in  Figure  3-4.  This  guidance  includes 
descriptions  of  the  Process  Phases,  Activities,  and  Activity-Flows  required  to  ensure  a  quality  conceptual  model, 
and  quality  ancillary  products.  The  products  themselves  will  be  described  further  in  Chapter  6. 

The  desired  process  guideline  is  based  on  these  desirable  characteristics,  which  best-practices  conceptual 
modeling  process  should  contain,  exhibit,  or  facilitate: 

COMPLIANCE: 

•  Comply  with  policies. 

•  Conform  to  enterprise  precepts  and  practices. 

•  Include  identification  of  stakeholders’  roles  and  responsibilities. 

•  Leverage  available  standards. 

•  Leverage  systems  engineering  and  information  management  best-practices. 

SUFFICIENCY: 

•  Provide  necessary  activities  to  the  conceptual  model  lifecycle. 

•  Contemplate  multiple  formalisms  and  views. 

•  Distinguish  between  Mission  Space  and  Simulation  (implementation)  Space  requirements  and  needs. 

•  Exhibit  sufficient  completeness  for  subsequent  intended  use. 

‘-ITILITIES’  -  this  represents  words  that  end  in  itilities,  such  as  utilities,  capabilities,  etc.: 

•  Give  developers  flexibility  to  apply  and  tailor  the  process. 

•  Provide  utility  and  efficiency. 

•  Allow  sufficient  expressiveness  and  flexibility. 

•  Foster  reusability. 

•  Foster  understanding. 
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QUALITY: 

•  Exhibit  sufficient  correctness  for  intended  use. 

•  Produce  quality  documentation. 

•  Enable  VV&A. 

A  five-phase  development  process  is  provided  commensurate  with  these  required  characteristics.  That  process 
is  shown  in  Figure  5-1,  and  its  process  elements  are  designated  as  follows: 

•  PP1  -  Initiate  Conceptual  Model  Development. 

•  PP2  -  Define  Conceptual  Model  Requirements  and  Knowledge  Needs. 

•  PP3  -  Acquire  Conceptual  Model  Knowledge. 

•  PP4  -  Design  the  Conceptual  Model. 

•  PP5  -  Build  the  Conceptual  Model. 


ppi 

INITIATE 

CM  Development 


PP2 

A 

DEFINE 

CM  Requirements  and 

V 

Knowledge  Needs 

*4 

PP3 

ACQUIRE 

CM  Knowledge 


PP4 

DESIGN 

CM 


r 

PP5 

BUILD 

\ 

CM 

Figure  5-1:  Conceptual  Model  Development  Phases. 


Each  development  phase  is  composed  of  a  corresponding  set  of  Process  Activities.  The  complete  collection  of 
activities  for  the  entire  process  is  shown  in  Figure  5-2.  Further  guidance  on  the  specific  phases  and  activities  is 
provided  in  the  sections  below,  and  technical  descriptions  of  each  Process  Activity  are  provided  in  the  text 
that  follows  and,  systematically  in  Annex  G. 
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Figure  5-2:  Conceptual  Model  Development  Process  Exhibiting 
Devolution  of  Process  Phases  to  Process  Activities. 

It  is  important  to  note  that  these  Process  Phases  and  Activities  need  not  be  executed  in  the  serial  order  implied 
by  their  enumerated  listing;  although,  the  ordinality  of  Process  Activities  associated  with  each  Process  Phase 
is  considered  to  be  logically  suggestive.  Pragmatically,  many  of  the  activities  may  be  executed  concurrently, 
in  multiple  iterations  or  out  of  numerical  sequence,  contingent  such  exigencies  a  team  structure  and  availability 
of  expertise,  availability  of  information,  election  of  spiral  or  other  recursive  implementation  techniques, 
or,  in  fact,  any  of  the  circumstances  that  are  the  inevitable  consequence  of  enterprise  operational  style  or 
business  practice.  The  only  limitations  to  task  activity  sequencing  is  the  necessity  to  satisfy  entry  conditions 
and  exit  conditions  for  each  activity,  as  defined  in  the  respective  sections  of  Annex  G. 

Figure  5-3  illustrates  such  one  such  non-linear  execution  of  the  global  process  through  the  use  of  a  state- 
transition  diagram.  In  the  example  in  the  figure,  SI... SI 3  indicate  each  state,  and  it  can  be  seen  that  the 
sequence  includes  execution  of  multiple  phases  in  parallel,  and  iterative  passes  through  the  process.  These 
states  may  also  involve  execution  of  individual  phased  Process  Activities  in  different  or  parallel  order. 
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Figure  5-3:  Example  Conceptual  Model  Development  Workflow. 

It  is  significant  to  note  that  the  process  specification  is  organized  and  presented  in  order  to  provide  the  greatest 
possible  discretion  to  the  conceptual  modeling  execution  agent,  while  encouraging  elements  that  have  been 
determined  to  comprise  best-practice.  In  that  spirit: 

•  These  defined  Process  Phases  and  Activities  are  provided  as  best-practices  in  conceptual  model 
development. 

•  This  process  may  be  tailored  as  needed  by  the  developer. 

•  The  Process  Activities  may  be  executed  in  any  sequence  allowed  by  the  entry  and  exit  criteria. 


5.2  CONCEPTUAL  MODEL  PROCESS  DESCRIPTION 

In  the  sections  that  follow,  discussion  of  conceptual  modeling  Process  Phases  and  their  component  Process 
Activities  are  provided.  The  intention  of  the  text  is  to  provide  a  plausible  explanation  and  rationale  of  the 
entire  effort  expected  to  be  necessary  and  sufficient  for  the  creation  and  management  of  military  simulation 
conceptual  models.  Information  is  provided  that  is  deemed: 

•  Useful  to  the  practitioner  in  understanding  motivation  for  particular  process  components; 

•  Constructively  prescriptive  in  conducting  conceptual  modeling; 

•  Effective  in  elaborating  on  special  circumstances  likely  to  apply  to  such  execution; 
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•  Liberating  to  the  practitioner  in  specializing  the  subject  guidance  contingent  particular  circumstances 
following  from  enterprise  and  task  peculiarities;  and 

•  Prescriptive  of  intentions  for  resulting  work-products. 

This  account  is  provided  as  a  complimentary  and  consistent  form  of  guidance  which,  when  taken  together 
with  the  systematically  tabular  guidance  specification  contained  in  Annex  G,  is  considered  necessary  and 
sufficient  to  inform  best-practices. 

5.2.1  Process  Phase  1  Guidance  -  Initiate  Conceptual  Model  Development 

The  conceptual  model  development  activity  in  this  phase  is  to  identify,  collect,  and  document  initial  needs, 
constraints,  and  policies  that  are  most  often  described  in  terms  of  the  underlying  simulation,  and  to  identify 
stakeholders  and  map  them  to  their  roles  and  responsibilities.  This  phase  is  critical  to  the  translation  of 
simulation  needs,  mandates,  and  constraints  into  those  for  the  conceptual  model  itself. 

Since  it  is  highly  unusual  for  conceptual  models  to  be  developed  for  their  own  sakes,  rather  than  in  the  context 
of  one  or  more  M&S  initiatives,  the  initiation  process  is  often  seen  as  external  to  the  conceptual  model 
process.  Yet  most  senior  stakeholders  in  the  enterprise  make  their  greatest  conceptual  model  development 
contributions  at  this  time.  Historically  these  contributions  rarely  have  been  documented  within  the  conceptual 
model  itself,  which  has  often  resulted  in  limited  conceptual  model  reusability  or  sub-optimum  representation 
due  to  assumed  constraints  and  mandates  that  dictate  the  form  and  content  of  the  conceptual  model. 

For  example: 

A  Joint  Forces  Commander  recognizes  the  need  to  provide  transportable  helicopter  simulators  in  the 
field  to  reduce  the  number  of  flight  hours  required  for  mission  training.  He  develops  an  M&S  need 
statement  to  address  the  problem,  and  an  Acquisition  Executive  decides  to  fund  the  development  of  the 
simulators  to  meet  the  need.  Due  to  the  urgency  of  the  problem,  the  Acquisition  Executive  allocates 
twenty  million  dollars  to  do  the  development  in  the  nine  remaining  months  of  the  current  year, 
and  tasks  an  Army  Program  Office  to  execute  the  mission.  The  Army  Program  Manager  knows  that  to 
execute  within  time  and  budget,  he  will  not  be  able  to  develop  a  validated  flight  model,  and  will  have 
to  use  a  surrogate,  which  will  limit  the  value  of  the  training  in  the  near-term.  He  decides  to  direct  the 
development  of  a  composable  architecture  so  that  he  can  drop  in  a  validated  flight  model  at  a  later 
date.  He  also  is  constrained  to  develop  the  simulators  using  existing  tools  and  using  mandated  software 
development  practices.  He  articulates  this  to  his  Group,  who  are  now  prepared  to  develop  the 
conceptual  model  for  the  simulation  effort. 

In  this  example,  conceptual  model  development  began  long  before  the  development  Group  received  their 
direction,  in  terms  of  the  constraints,  policies,  and  mandates  limiting  the  simulation  development  effort. 
As  mentioned  above,  an  ideal  conceptual  model  is  said  to  be  implementation  independent.  And  a  conceptual 
model  can  certainly  be  developed  to  support  the  example  above,  without  specifying  application  constraints. 
But  even  if  the  conceptual  model  does  not  explicitly  reference  these  constraints,  those  constraints  will  still 
bind  and  shape  it,  and  as  will  be  shown  in  the  next  process  steps,  the  conceptual  model  requirements 
definition  and  knowledge  acquisition  will  be  highly  impacted  by  the  decisions  made  by  the  senior 
stakeholders. 

Therefore,  in  order  to  translate  and  document  the  impacts  of  the  M&S  development  effort  to  the  conceptual 
model,  the  following  Process  Activities  must  take  place: 
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ORGANIZATION 


•  PA1. 1  -  Identify  and  Map  Stakeholder  Responsibilities. 

•  PA1 .2  -  Define  Purpose  and  Intended  Use  of  M&S  effort. 

•  PA1 .3  -  Identify  Constraints  on  the  M&S  effort. 

•  PA1 .4  -  Impose  Mandatory  Enterprise  Policies. 

The  relationships  among  these  Process  Activities  and  with  their  products  are  shown  in  Figure  5-4. 


act  PP1  Activity  Diagram:  Initiate  CM  Development 


‘  Start  PP1 
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Figure  5-4:  Process  Phase  1  (PP1)  Activity  Diagram. 
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Each  Process  Activity  is  described  below,  and  is  further  specified  in  Annex  G. 

5.2. 1.1  PA1.1  -  Identify  and  Map  Stakeholder  Responsibilities 

A  conceptual  model  primarily  exists  for  the  benefit  of  its  stakeholders.  Stakeholders  must  be  identified  to 
support  the  conceptual  model  development  process:  to  support  requirements  development  and  knowledge 
acquisition,  and  to  impact  the  design  and  build  of  the  conceptual  model.  Stakeholders  and  their  roles  must  be 
known  before  views  can  be  determined.  Stakeholder  perspectives  will  drive  terminology  and  will  impact  the 
selection  of  models  and  relationships. 

This  Process  Activity  involves  three  kinds  of  things:  Lists  of  actual  points  of  contact,  by  name  or  office; 
identification  of  relevant  stakeholder  roles  as  described  in  Section  4.3;  and  a  mapping  of  the  points  of  contact 
to  the  roles. 

Points  of  contact  may  be  generated  from  lists,  employee  roles,  organizational  charts,  personnel  databases, 
referrals,  resumes,  biographies,  contract  labor  categories,  or  any  other  programmatic  or  administrative  means. 

Roles  must  be  defined  by  analysis  of  the  PA1.2  defined  purpose  and  intended  use  of  the  M&S  effort  to  the 
stakeholder  classes  described  above,  tailored  to  the  particular  application. 

Mapping  of  the  two  will  most  likely  involve  M  to  N  mapping,  given  that  many  individuals  or  offices  can  often 
have  multiple  roles  in  a  particular  conceptual  model  development,  and  many  roles  include  multiple  people  for 
any  realistically  sized  effort. 

In  the  example  above,  the  points  of  contact  “Joint  Forces  Commander”  and  “Acquisition  Executive”  might 
map  to  “Sponsor”,  and  “Army  Program  Manager”  would  likely  map  to  the  stakeholder  role  of  “Producer”. 

This  activity  produces  the  Pl.l  -  Stakeholder  Descriptions,  which  are  used  to  derive  conceptual  model 
requirements  and  conceptual  model  knowledge  needs. 


5.2. 1.2  PA1.2  -  Define  Purpose  and  Intended  Use  of  M&S  Effort 

This  Process  Activity  may  begin  upon  stated  or  implied  intent  to  develop  a  model,  simulation,  or  conceptual 
model.  This  intent  may  come  in  the  form  of  task  orders,  mission  needs  statements,  user  requirement 
documents,  requests  for  proposal,  statements  of  work,  formal  or  informal  directives,  test  agreements,  oral  or 
written  orders,  or  any  combination  of  like  manners  of  communication. 

The  purpose  of  this  activity  is  to  compile  all  these  M&S  source  documents  and  implied  intents  into  a  single 
set,  to  deconflict  the  elements  of  the  set,  and  to  provide  this  reconciled,  definitive  description  of  intent  to  the 
conceptual  model  developers,  written  in  terms  of  descriptions  of  needs  for  the  conceptual  model. 

It  may  be  possible  that  multiple  references  to  intent  cannot  be  reconciled,  as  in  the  example  above,  where  the 
Joint  Forces  Commander  wants  to  train  pilots  but  the  Army  Program  Manager  is  not  providing  a  validated 
flight  model.  In  that  case,  even  these  potentially  conflicting  or  mutually  exclusive  intents  must  be  documented 
and  highlighted,  as  they  will  likely  drive  complexity  into  the  conceptual  model,  as  the  Army  Program 
Manager’s  decision  to  develop  a  composable  architecture  surely  would  have  done. 

This  activity  produces  the  PI. 2  -  Intended  Use  Statement,  which  is  used  to  derive  conceptual  model 
requirements  and  conceptual  model  knowledge  needs. 
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5.2. 1.3  PA1.3  -  Identify  Constraints  on  the  M&S  Effort 

As  in  the  example,  time  and  resources  can  constrain  the  conceptual  model  design,  as  can  the  intended  use 
itself.  These  M&S  constraints  in  turn  constrain  the  conceptual  model  development,  and  impact  the  reusability 
and  implementation  independence. 

And  as  in  PA1.2,  information  pools  such  as  documented  resource  constraints,  senior  stakeholder  preferences 
and  requirements,  planning/budgeting  management  limitations,  legacy  M&S  preferences  and  availability,  data 
availability,  enterprise  preferences,  and  such,  must  be  collected,  integrated,  and  de-conflicted  into  a  self- 
consistent  set  of  descriptions  of  M&S  constraints. 

This  activity,  combined  with  PA1.4,  is  necessary  to  produce  PI. 3  -  Constraints  and  Policies,  which  is  used  to 
derive  conceptual  model  requirements  and  conceptual  model  knowledge  needs. 

5.2. 1.4  PA1.4  -  Impose  Mandatory  Enterprise  Policies 

In  this  Process  Activity,  developers  collect  information  from  enterprise  standard  operating  procedures, 
industry  and  government  standards,  enterprise  executive  mandates,  law,  agency  regulations,  agency  directives, 
written  policy,  implied  enterprise  mandates,  and  other  references  relating  to  Enterprise  Policy  Mandates. 
This  data  must  be  collected,  integrated,  and  de-conflicted  into  a  self-consistent  set  of  descriptions  of  policies. 

Examples  of  enterprise  mandates  include  the  US  Department  of  Defense  mandate  to  use  High  Level 
Architecture  (HLA),  some  industries  standardizing  on  UML,  or  even  a  small  business’s  decision  to  use  a 
proprietary  software  tool  for  competitive  advantage.  This  activity  is  where  the  enterprise  has  tailored  the 
intended  use  and  constraints  to  its  own  interests,  and  that  tailoring  gets  reflected  in  the  initial  state  of  the 
conceptual  model. 

This  activity,  combined  with  PA1.3,  is  necessary  to  produce  PI. 3  -  Constraints  and  Policies,  which  is  used  to 
derive  conceptual  model  requirements  and  conceptual  model  knowledge  needs. 

Listed  below  are  the  points  of  emphasis: 

•  The  INITIATE  phase  of  conceptual  model  development  is  a  critical  and  often  overlooked  set  of 
activities  that  must  be  understood  and  documented. 

•  These  activities  are  necessary  to  document  stakeholder  roles,  conceptual  model  requirements, 
policies,  and  mandates. 

•  This  phase  sets  the  initial  state  of  the  conceptual  model. 

•  In  mature  enterprises,  much  of  this  initial  state  is  quite  repeatable  from  one  conceptual  model  activity 
to  the  next,  and  might  generate  documents  that  are  highly  reusable  in  subsequent  efforts. 

5.2.2  Process  Phase  2  Guidance  -  Define  Conceptual  Model  Requirements  and  Knowledge 
Needs 

Overview  of  Process  Activities  and  Products  -  The  second  Process  Phase  in  the  conceptual  model  development 
process  consists  of  four  Process  Activities  in  a  simple  sequence  as  shown  in  Figure  5-5.  This  Process  Phase  takes 
two  input  products  (PI. 2  -  Need  Statement  and  PI. 3  -  Constraints  and  Policies)  and  produces  two  output 
products  (P2.1  -  Conceptual  Model  Requirement  Specification  and  P2.2  -  Conceptual  Model  Knowledge 
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Acquisition  Needs).  A  preliminary  product  is  used  to  record  requirements  during  the  Process  Phase  execution 
before  they  have  been  synergized  and  verified. 


act  PP2  Activity  Diagram:  Define  CM  Requirements  and  Knowledge  Needs 
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Figure  5-5:  Process  Phase  2:  Define  Conceptual  Model  Requirements  and  Knowledge  Needs. 


5.2.2.1  PA2.1  -  Identify,  Analyze  and  Record  Conceptual  Model,  Mission  and  Simulation 

Space  Requirements 

Process  Activity  2.1  refers  to  requirements  grouped  into  three  “Spaces”:  Conceptual  Model  Space,  Mission 
Space  and  Simulation  Space.  The  concepts  of  these  “Spaces”  are  explained  in  Chapter  4,  Section  4. 1  Scope  and 
Definitions  and  an  example  are  presented  in  Annex  I. 

This  Process  Activity  refines  the  need  statement  by  detailing  the  implications  of  the  needs  in  a  more  explicit 
set  of  requirements.  It  can  be  described  as  a  kind  of  translation  process  from  qualitative  and  informal 
statements  in  the  “language”  of  the  client  (needs)  to  more  quantified  and  precise  statements  of  content  and 
attributes  of  the  required  conceptual  model  (requirements). 
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Analyzing  the  requirements  is  a  process  of  reviewing  and  evaluating  the  requirements  to  ensure  that  they  are 
complete,  consistent  and  correct. 

Typical  requirements  originating  from  the  conceptual  model  space  may  include: 

•  The  views  needed  of  the  conceptual  model  by  different  stakeholders. 

•  The  level  of  formality  needed  by  stakeholders. 

•  Mandatory  tools,  documentation  formats,  notations,  etc. 

•  Mandated  conceptual  model  characteristics. 

•  What  policy  to  follow  to  validate  the  conceptual  model. 

•  What  acceptance  criteria  to  apply  in  validation. 

In  order  to  prepare  the  acceptance  of  the  results  of  the  V&V  effort  by  the  stakeholders  used  in  PA5.5  (Ensure 
Acceptance  of  Conceptual  Model  by  Authorized  Stakeholder),  it  must  be  determined  what  information  the 
stakeholders  require  for  their  acceptance  decision-making  process. 

Typical  requirements  originating  from  the  mission  space  may  include: 

•  Definition  of  what  parts  of  the  mission  space  to  be  included  in  the  conceptual  model  (Scope). 

•  Questions  to  be  answered  by  the  modeling  and  simulation  effort  (Critical  Operational  Issues  (COIs)). 

•  Level  of  realism  and  detail  needed  in  order  to  address  the  COIs  (Abstractness  characteristics). 

•  How  the  degree  of  satisfaction  of  operational  issues  are  to  be  measured  (Measures  of  effectiveness). 

Typical  requirements  originating  from  the  simulation  space  may  include: 

•  Intended  use  of  the  model  (e.g.,  training,  feasibility  study,  trade-off  studies,  performance  analysis). 

•  Implementation  strategy  and  choice  of  fundamental  technology. 

•  Explicit  performance  constraints  (e.g.,  real-time  requirements,  Monte  Carlo  simulation  requirements). 

•  Requirement  to  interface  with  existing  software,  hardware  equipment  or  human  operators. 

5.2.2.2  PA2.2  -  Verify  Requirements  with  Respect  to  Needs,  Constraints  and  Policies 

Process  Activity  2.2  shall  ensure  that  the  requirement  specification  satisfies  important  quality  criteria. 
As  'described  in  Section  4.7  V&V,  an  AF  is  built  during  the  V&V  work.  For  the  first  part  of  the  AF  a  goal- 
oriented  approach  is  taken.  Starting  with  the  top  goal,  criteria  are  derived  in  a  hierarchical  fashion.  A  part  of 
those  criteria  deal  with  the  requirements  of  the  conceptual  model  space,  the  mission  space  and  the  simulation 
space.  The  requirements  are  to  be  verified  against  the  criteria  in  that  part  of  the  AF. 

Typical  quality  criteria  are: 

•  Completeness:  All  needs,  constraints  and  policies  are  covered  by  one  or  more  requirements. 

•  Traceability:  Every  requirement  statement  can  be  referred  to  a  corresponding  need,  constraint  or 
policy  statement. 

•  Correctness:  All  needs,  constraints  and  policies  have  been  interpreted  as  the  sponsor  intended. 

•  Un-ambiguity:  The  requirement  is  given  a  form  that  avoids  misinterpretation. 
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Other  possible  criteria  are  consistency,  adequacy,  measurability,  pertinence,  feasibility,  comprehensibility  and 
good  structuring. 

Completeness  ensures  that  all  requirements  implicit  in  the  need  statement  and  applicable  constraints  and 
policies  are  accounted  for.  Traceability  ensures  that  no  requirement  that  is  not  implied  by  these  inputs  has 
found  its  way  into  the  requirement  specification  product.  That  is,  there  should  be  no  element  of  invention  at 
this  stage.  The  requirement  specification  shall  simply  be  an  accurate  reflection  of  preceding  products. 

The  process  of  verifying  the  requirements  may  however  reveal  inconsistencies,  inaccuracies  or  omissions  in 
the  input  products.  It  is  therefore  a  good  opportunity  to  clarify  and  adjust  Phase  1  products  before  weaknesses 
are  propagated  to  downstream  Process  Phases. 

5.2.2.3  PA2.3  -  Synergize  Conceptual  Model,  Mission  and  Simulation  Space  Requirements 

Conceptual  model  space,  mission  space  and  simulation  space  requirements  may  in  some  cases  be  incompatible. 
There  may  therefore  be  a  need  for  harmonizing  any  conflicting  requirements.  This  is  taken  care  of  in  Process 
Activity  2.3. 

5.2.2.4  PA2.4  -  Derive  Mission  and  Simulation  Space  Knowledge  Needs 

Process  Activity  2.4  shall  produce  a  description  of  the  knowledge  needed  by  the  developers  of  the  conceptual 
model.  These  needs  must  be  based  on  the  conceptual  model  requirement  specification  and  should  identify 
relevant  knowledge: 

•  Used  by  military  personnel  in  the  execution  of  their  profession  (tactics,  techniques  and  procedures). 

•  About  the  scientific  basis  for  military  technology. 

•  About  construction  and  performance  of  military  technology. 

•  About  simulation  methods  and  technologies. 

Note  that  only  the  knowledge  needs  are  described  at  this  stage,  not  the  knowledge  itself  (which  is  the  task  of 
Process  Phase  3).  It  is  important  to  be  careful  in  limiting  the  knowledge  needs  to  what  is  strictly  necessary  for 
the  conceptual  model  to  be  constructed.  It  is  easy  to  be  carried  away  by  the  wealth  of  information  available 
and  making  the  knowledge  acquisition  task  more  onerous  than  necessary. 

Some  aspects  that  should  be  considered  when  deriving  knowledge  needs  are: 

•  The  entities  and  behaviours  that  must  be  described  by  the  model. 

•  The  granularity  or  level  of  detailed  needed  in  describing  the  phenomena  to  be  modelled. 

•  Which  simplifying  assumptions  can  be  allowed  and  what  causal  relationships  must  be  included  in  the 
model. 

When  assessing  these  aspects  the  knowledge  needed  must  finally  be  dictated  by  what  questions  the  model  is 
supposed  to  answer,  that  is  the  purpose  of  the  model. 

For  example: 

A  simulation  model  shall  be  used  to  evaluate  the  effectiveness  of  flare  countermeasures  against  infrared 
homing  anti-ship  missiles.  In  such  a  setting  we  may  need  the  following  type  of  knowledge: 
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•  Missile  flight  trajectory,  agility  and  speed. 

•  Missile  seeker  sensitivity,  field  of  view  and  tracking  ability. 

•  Missile  seeker  countermeasure  discrimination  ability. 

•  Countermeasure  blooming  profile,  intensity  and  duration. 

•  Countermeasure  alternative  tactics  for  deployment. 

•  Ship  IR  signature. 

•  Ship  maneuverability. 

•  Ship  alternative  maneuvering  tactics. 

•  Environmental  conditions  influencing  background  IR  radiation. 

•  Environmental  conditions  influencing  IR  radiation  propagation. 

•  Environmental  conditions  influencing  flare  movement. 

Listed  below  are  the  points  of  emphasis: 

•  Bring  any  hidden  assumptions  into  the  open  by  spelling  them  out  explicitly  in  the  form  of  requirements 
and  so  reduce  room  for  alternative  interpretations. 

•  The  knowledge  acquisition  needs  should  be  limited  to  what  is  strictly  needed. 

•  Leverage  earlier  requirements  and  knowledge  specifications. 

5.2.3  Process  Phase  3  Guidance  -  Acquire  Conceptual  Model  Knowledge 

The  Phase  3  in  the  NATO  conceptual  modeling  process,  called  “Acquire  Conceptual  Model  Knowledge”,  will 
begin  by  taking  the  two  products  generated  in  Phase  2,  which  are  P2.1  -  Conceptual  Model  Requirement 
Specification  and  P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs,  as  input.  These  inputs  will  be  used 
to  identify  the  authoritative  knowledge  sources  for  a  particular  piece  of  knowledge.  Thus  Phase  3  is  where  the 
knowledge  required  for  description  of  a  certain  mission  space  will  be  acquired.  This  phase  will,  after 
gathering,  structuring  and  documenting  and  review  the  validity  of  that  acquired  knowledge  with  respect  to  the 
authoritative  knowledge  sources,  produce  a  product  called  P3.1  -  Validated  Knowledge.  This  product  will 
serve  as  the  foundation  for  designing  and  building  the  final  conceptual  model. 

Given  that  a  conceptual  model  repository  already  exists,  this  phase  will  begin  by  looking  for  reusable 
knowledge  that  may  already  be  in  the  conceptual  model  repository  and  can  be  completely  or  partially  usable 
for  this  new  need.  If  not,  the  lack  of  knowledge  is  identified,  along  with  the  gaps  that  must  be  filled. 
But  before  that  knowledge  can  be  acquired  the  authoritative  knowledge  sources  should  be  identified.  After 
that,  the  required  knowledge  will  be  gathered,  structured,  and  documented,  and  finally  analyzed  for  necessity 
and  sufficiency.  After  that,  enough  knowledge  should  exist  to  either  generate  a  Domain  Ontology  for  this 
particular  mission  space  or  to  extend  the  existing  Domain  Ontology.  The  last  activity  in  this  phase  will  be  to 
review  the  validity  of  the  acquired  knowledge  with  respect  to  the  authoritative  knowledge  sources. 

The  third  phase  in  the  conceptual  model  development  process  consists  of  six  Process  Activities  as  shown  in 
Figure  5-6. 
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Figure  5-6:  Process  Phase  3  Activity  Diagram:  Acquire  Conceptual  Model  Knowledge. 


5.2.3. 1  PA3.1  -  Identify  Authoritative  Knowledge  Sources 

This  activity  is  about  identifying  authoritative  knowledge  sources  to  fetch  correct  and  authoritative 
information  that  describes  a  certain  domain.  Knowledge  Acquisition  (KA)  belongs  to  the  initial  phases  of 
almost  any  kind  of  system  development  process.  There  is  no  specific  methodology  for  identifying  appropriate 
sources  for  KA  but  the  important  issue  here  is  to  rely  only  on  authoritative  knowledge  sources,  those 
authorised  by  some  organisation/authority  beforehand  (who  this  person  or  agency  should  be  is  beyond  the 
scope  of  this  report).  These  sources  can  be  anything  from  books,  web  information,  papers,  regulations 
documents,  pictures,  maps,  and  case  studies,  but  perhaps  most  important  of  all  interviews  with  SMEs.  Having 
a  deeper  understanding  of  the  problem  domain  and  (preferably)  having  experience  of  the  particular  area  are 
necessary  qualities  for  success. 
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5.2.3.2  PA3.2  -  Search  for  the  Reusable  Knowledge  in  the  Conceptual  Model  Repository 

A  successful  result  of  this  activity  requires  that  good  work  is  done  in  previous  phases  to  identify  the  purpose, 
need,  and  requirements  that  are  posed  on  the  acquired  information.  This  list  of  needs  and  requirements  will  be 
the  foundation  for  building  the  necessary  queries  to  the  conceptual  model  repository.  Keep  in  mind  that 
several  qualitative  properties  are  critically  important  to  search  and  find  either  the  reusable  knowledge 
component  (part  of  a  conceptual  model)  or  a  complete  conceptual  model  fulfilling  a  specific  need.  One  is  to 
try  to  model  knowledge  in  smaller  components  that  makes  reusability  easier.  The  other  property  is  to  have  a 
degree  of  formalisation  and  semantic  description  that  makes  it  possible  to  compose  smaller  components  for 
building  the  needed  conceptual  model.  The  third  is  to  have  good  Meta  data  addressing  artefacts  in  the 
Conceptual  Model  Repository;  this  makes  it  possible  to  easily  find  the  knowledge  which  corresponds  to  the 
need. 


5.2.3.3  PA3.3  -  Identify  Knowledge  Gaps  and  Bounds 

This  activity  concerns  whether  the  knowledge  retrieved  from  an  existing  conceptual  model  repository  is  in 
accordance  with  the  requirements;  here  the  reusability  of  already  gathered  conceptual  models  or  components 
will  be  examined  to  see  if  they  can  be  used  for  the  new  purpose.  The  outcome  aids  in  identifying  what  is 
missing.  This  activity  will  be  considered  only  if  the  result  of  the  previous  activity  (search  for  the  reusable 
knowledge  in  the  conceptual  model  repository)  has  been  that  the  knowledge  components  have  been  found  that 
only  partly  fulfils  the  need.  These  are  then  compared  with  the  requirements  to  make  certain  that  either  the  set 
of  requirements  are  fulfilled  or  alternately,  if  knowledge  corresponding  to  a  specific  requirement  is  missing, 
further  knowledge  acquisition  will  be  taken  care  of  in  the  next  activity. 

5.2.3.4  PA3.4  -  Gather,  Structure  and  Document  Knowledge 

Information  sources  for  military  activities  can  be  anything  from  instructions,  books,  military  doctrines,  military 
scenarios,  and  case  studies  to  military  experts,  Subject-Matter  Experts,  etc.  However,  the  information  that  is 
needed  for  a  certain  purpose  is  often  not  documented  anywhere  and  is  only  available  through  SMEs.  Since  there 
is  no  easy  way  to  access  this  knowledge  and  it  is  often  expensive  to  gather,  recount,  and  store.  This  activity  is 
about  gathering,  structuring  and  documenting  this  important  knowledge.  Certain  military  knowledge  is  often  not 
documented  anywhere  and  is  only  available  through  SMEs.  The  art  of  gathering  this  information  from  SMEs  is 
usually  called  Knowledge  Elicitation  (KE)  and  is  considered  to  be  one  of  the  greatest  challenges  of  KA.  Another 
challenge  is  to  capture  and  obtain  tacit  knowledge  -  things  that  the  expert  does  routinely,  without  much  thought 
and  considered  obvious  by  the  expert.  The  more  knowledge  an  expert  possesses,  more  is  often  considered 
obvious  and  it  is  usually  more  difficult  for  him  to  recount  what  they  know. 

5.2.3.5  PA3.5  -  Generate/Extend  a  Domain  Ontology 

The  previous  activity  has  captured  and  documented  new  knowledge  about  a  certain  military  activity  that  did 
not  already  exist  in  the  conceptual  model  repository.  It  means  new  knowledge  most  likely  will  introduce  new 
military  concepts,  properties,  relations,  and  constraints  which  should  be  stored  in  some  kind  of  knowledge 
base  for  future  use  and  reuse.  This  activity  covers  structuring,  tagging,  and  storing  the  gathered  information 
either  as  new  domain  ontology  or  as  an  extension  to  an  existing  one. 

5.2.3.6  PA3.6  -  Review  Validity  of  Knowledge  with  Respect  to  the  Authoritative  Knowledge  Sources 

This  activity  is  about  evaluation  of  the  validity  of  acquired  knowledge  with  respect  to  authoritative  knowledge 
sources.  This  occurs  by  examining  whether  the  result  of  the  knowledge  acquisition  phase  is  acceptable  to  the 
owner  of  the  mission  space  (the  SME).  It  is  about  checking  with  the  experts,  whose  realities  have  been 
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captured  and  documented,  to  see  if  the  documented  knowledge  is  correct  and  completely  represents  the 
activity.  This  is  preferably  performed  by  a  VV&A  agent. 

A  challenge  of  knowledge  acquisition  is  that  it  often  begins  with  the  gathering  of  information  from 
descriptions  about  a  certain  domain,  through  books,  papers,  tutorials,  etc.  All  stored  information  is  static  while 
reality  is  dynamic  and  in  constant  change,  which,  if  nothing  is  done,  results  in  information  that  has  been 
correctly  gathered,  but  over  time,  becomes  out-dated.  Another  challenge  may  appear  when  several  experts 
have  to  be  involved,  where  each  expert  might  use  different  terminology  or  emphasize  different  things. 
A  method  for  solving  this  can  be  to  have  one  expert  write  something  and  then  use  a  system  of  peer-review  to 
iteratively  refine  the  data.  However  a  good  methodology  for  keeping  the  generated  conceptual  models  updated 
over  time  is  required. 

5.2.4  Process  Phase  4  Guidance  -  Design  Conceptual  Model 

The  objective  of  this  phase  is  to  translate  the  conceptual  model  requirements  into  a  conceptual  model  design 
preparing  to  build  the  actual  conceptual  model. 

The  conceptual  model  design  explicitly  trades  off  and  balances  conflicting  requirements,  such  as  the 
stakeholders  understanding  and  involvement  in  the  simulation  development  process  and  enterprise  mandated 
policies. 

It  may  seem  artificial  to  explicitly  separate  the  design  and  the  building.  However,  a  conscious  conceptual 
model  design  makes  the  producers  aware  of  their  own  bias  relative  to  the  stakeholders’  bias. 

The  conceptual  model  design  is  basically  a  top-down  selection  of  conceptual  primitives,  model  kinds,  views, 
formalisms  and  notations.  The  selection  can  be  influenced  by  the  bottom-up  choice  of  reusing  existing 
conceptual  model  artefacts.  The  design  must  be  submitted  to  an  evaluation  against  the  conceptual  model 
requirements  for  typical  quality  criteria  like  completeness  and  fitness  for  purpose. 

The  conceptual  model  design  is  divided  in  six  activities: 

•  PA4.1  -  Search  for  Existing  Conceptual  Models  that  May  be  Partially  or  Fully  Re-Used  to  Support 
the  Current  Conceptual  Model  Development. 

•  PA4.2  -  Identify  and  Select  Conceptual  Primitives  and  Model  Kinds  to  Represent  Acquired  Knowledge. 

•  PA4.3  -  Select  Formalism(s)  for  Conceptual  Model  Specification. 

•  PA4.4  -  Select  Views  to  Support  Stakeholders. 

•  PA4.5  -  Select  a  Notation  Suitable  to  Express  the  Chosen  Formalism. 

•  PA4.6  -  Evaluate  Design  for  Adequacy/Relevance  with  Respect  to  Requirements. 

As  shown  in  Figure  5-7,  conceptual  primitives,  model  kinds,  formalisms,  views  and  notations  are  implicitly 
entangled,  but  they  are  artificially  separated  to  make  the  producers  aware  of  the  interrelation  of  design  choices 
and  their  consequences  on  meeting  the  stakeholders’  expectations  and  the  conceptual  model  characteristics 
requirements.  This  separation  is  necessary  to  be  intentionally  selective  on  the  conceptual  model  design 
options.  It  is  an  investment  against  the  risk  of  uninformed  use  of  conceptual  model  components. 
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Figure  5-7:  Conceptual  Model  Components. 

The  activity  diagram  in  Figure  5-8  shows  how  the  activities  are  interrelated. 
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act  PP4  Activity  Diagram:  Design  CM 


Figure  5-8:  Process  Phase  4  (PP4)  Activity  Diagram. 
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There  is  no  mandatory  order  in  PA4.1  to  PA4.5.  They  all  input  to  the  preliminary  design  for  evaluation  in 
PA4.6  and  for  acceptance  by  the  stakeholders  as  the  Product  4.1  -  Conceptual  Model  Design.  Several  preliminary 
design  and  evaluation  cycles  are  usually  required  to  finally  pass  the  evaluation.  Experience  will  allow  passing 
the  evaluation  with  fewer  cycles. 

Annex  I  presents  several  examples  of  different  conceptual  model  designs.  The  example  in  Annex  I,  Section  1.5 
specifically  emphasizes  on  the  iterative  conceptual  model  design  process. 

5.2.4.1  PA4.1  -  Search  for  Existing  Conceptual  Models  that  May  be  Partially  or  Fully  Re-Used 
to  Support  the  Current  Conceptual  Modeling  Development 

In  this  Process  Activity,  the  producer  of  the  conceptual  model  is  searching  for  existing  partial  conceptual 
models  with  the  intention  of  reusing  it  for  the  conceptual  model  design.  Typical  search  criteria  are  driven  by 
mandated  enterprise  policies,  the  obligation  for  stakeholder’s  involvement  and  relevant  common  practice. 
Even  if  the  producer  cannot  find  an  appropriate  conceptual  model  design  that  suits  all  of  these  criteria, 
a  conceptual  model  design  that  has  been  used  successfully  might  be  a  good  starting  point.  Future  iterations  are 
likely  to  refine  search  criteria  and  hint  of  other  existing  designs. 

Motivations  for  reusing  conceptual  model  designs  are  to  avoid  discussions  that  have  been  settled  in  the  past 
and  endorse  common  practice  within  a  relevant  community. 

5.2.4.2  PA4.2  -  Identify  and  Select  Conceptual  Primitives  and  Model  Kinds  to  Represent  Acquired 
Knowledge 

In  this  Process  Activity,  the  producers  select  suitable  conceptual  primitives  that  will  capture  the  knowledge 
elements  and  the  model  kinds  that  will  organize  the  conceptual  primitives. 

The  producers  do  not  need  to  know  the  exact  knowledge  content  to  be  modelled,  but  need  to  have  a  rough  idea 
of  the  domain  area  and  the  type  of  knowledge.  For  example,  decision  support  knowledge  may  require  action- 
related  conceptual  primitives  while  system  knowledge  may  require  function-related  ones. 

The  producers  need  to  analyze  the  conceptual  model  characteristic  requirements  from  P2.1  -  Conceptual 
Model  Requirement  Specification  to  derive  the  implications  on  conceptual  primitives  and  model  kinds. 

The  producers  need  to  know  about  the  conceptual  primitive  and  model  kind  options  either  from  the  literature 
or  from  experience.  There  is  a  critical  need  to  further  develop  the  body  of  knowledge  necessary  to  categorize 
the  conceptual  primitives  and  model  kinds  in  terms  their  implications  on  conceptual  model  characteristics  on 
the  other  conceptual  model  components.  For  example,  it  would  be  useful  to  understand  how  characteristics 
such  as  expressiveness,  computability  or  level  of  detail  influence  the  choice  of  conceptual  primitives  and 
model  kinds. 

Each  time  the  conceptual  primitives  and  model  kinds  are  updated;  they  influence  other  conceptual  model 
components,  the  existing  conceptual  model  artefact  and  its  Meta  data,  including  its  characteristics  and  its 
validation  status.  Conversely  each  time  other  conceptual  model  components  and  requirements  change, 
the  conceptual  primitives  and  model  kinds  will  be  influenced. 
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5.2.4.3  PA4.3  -  Select  Formalism(s)  for  Conceptual  Model  Specification 

In  this  Process  Activity,  one  or  more  formalisms  are  selected  to  be  enforced  in  the  build  phase.  A  formalism  is 
the  constraint  of  form  over  content.  A  formalism  can  be  more  or  less  formal.  The  formality  is  the  amount  of 
constraints  imposed  on  the  form.  Informal  representations  such  as  loose  or  structured  natural  language  would 
not  be  considered  as  a  conceptual  model  (e.g.,  glossaries,  dictionaries,  thesaurus,  and  hierarchies).  A  formal 
representation  imposes  an  artificially  defined  formalism.  A  more  formal  formalism  clearly  defines  concepts 
with  semantics,  theorems  and  proofs  that  enable  inferences.  A  higher  level  of  formality  fosters  some 
conceptual  model  characteristics  such  as  consistency,  interoperability,  reusability,  computability  and 
executability. 

Several  formalisms  may  be  required  to  bridge  the  gap  between  different  stakeholders.  For  example,  decision¬ 
makers,  simulation  end-users,  simulation  developers  and  machines  may  feel  more  comfortable  to  retrieve 
meaningful  and  valuable  input  from  a  particular  paradigm  or  a  particular  level  of  formality.  The  conceptual 
model  design  is  meant  to  cope  with  contradictory  requirements  such  as  expressiveness  for  human 
understandability  (e.g.,  Mind  Map  or  UML)  and  computability  or  executability  for  machine  readability  (e.g.,  Web 
Ontology  Language  (OWL)). 

The  formalisms  are  carefully  chosen  according  to  the  policies,  the  characteristics  and  the  stakeholders’ 
requirements  from  P2.1  -  Conceptual  Model  Requirement  Specification.  In  an  iterative  and  incremental 
design  process,  the  choice  of  formalism  is  driven  by  and  influences  the  other  conceptual  model  components, 
the  existing  conceptual  model  artefact  and  its  Meta  data,  including  its  characteristics  and  its  validation  status. 

The  producers  need  to  know  about  the  formalism  options  either  from  the  literature  or  from  experience.  There 
is  a  critical  need  to  further  develop  the  body  of  knowledge  necessary  to  categorize  the  formalisms  in  terms 
their  implications  on  conceptual  model  characteristics  and  on  the  other  conceptual  model  components. 

5.2.4.4  PA4.4  -  Select  Views  to  Support  Stakeholders 

In  this  Process  Activity,  views  are  selected  to  fit  the  purpose  of  the  different  stakeholders.  Views  are  the 
graphical  user  interfaces  of  the  conceptual  model.  When  selecting  views,  the  producers  are  always  biased  by 
their  own  way  of  “seeing”  the  problem.  It  is  of  utmost  importance  to  make  an  elective  choice  of  views  that 
support  the  stakeholders’  requirements. 

A  complete  conceptual  model  design  generally  includes  multiple  views.  For  example,  Department  of  Defense 
Architecture  Framework  (DoDAF)/NATO  Architecture  Framework  (NAF)  includes  an  Operational,  System 
and  Technical  views.  UML  offers  Design,  Process,  Component,  Deployment,  Use  Case  views. 

A  view  can  be  represented  by  several  model  kinds.  For  example,  the  UML  Process  view  represents  dynamic 
aspects  using  State,  Activity,  Sequence  and  Collaboration  diagrams. 

Although  views  are  prescribed  by  P2.1  -  Conceptual  Model  Requirement  Specification,  many  other  latent 
views  can  emerge  from  available  conceptual  primitives  and  model  kinds  if  a  stakeholder  requires  it.  In  an 
iterative  and  incremental  design  process,  the  stakeholders’  representation  requirements  and  the  views  can 
evolve  as  the  conceptual  model  is  being  built. 

The  producers  need  to  know  about  the  view  options  either  from  the  literature  or  from  experience.  There  is  a 
critical  need  to  further  develop  the  body  of  knowledge  necessary  to  determine  which  views  are  appropriate  fit 
which  stakeholders’  representation  requirements  and  which  conceptual  primitives  and  model  kinds  make 
meaningful  views. 
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If  formalisms  have  been  selected  in  the  preliminary  conceptual  model  design,  they  may  impact  on  the 
discretionary  specification  of  views.  There  may  be  more  than  one  way  of  presenting  a  view  and  a  specific 
formalism  may  impose  specifications  on  the  view. 

5.2.4.5  PA4.5  -  Select  a  Notation  Suitable  to  Express  the  Chosen  Formalism 

In  this  Process  Activity,  suitable  notations  are  elected  to  express  the  formalisms,  the  conceptual  primitives, 
the  model  kinds  and  the  views  selected  in  the  preliminary  conceptual  model  design.  The  choice  is  driven  by 
P2.1  -  Conceptual  Model  Requirement  Specification.  For  example,  in  Annex  I,  Section  1.2,  the  Use  Case  view 
was  expressed  using  a  custom  pictogram  notation  instead  of  the  UML  notation  to  meet  an  expressiveness 
requirement.  Introducing  the  UML  notation  to  non-initiated  decision-makers  could  have  added  an  overhead  if 
not  a  misunderstanding. 

The  producers  need  to  know  about  the  notation  options  either  from  the  literature  or  from  experience.  There  is 
a  critical  need  to  develop  the  body  of  knowledge  necessary  to  explicitly  categorize  the  notations  in  terms  of 
supported  formalisms,  conceptual  primitives,  model  kinds,  and  views. 

In  an  iterative  and  incremental  design  process,  the  selected  notations  need  to  be  adapted  when  the  requirements 
and  the  conceptual  model  design  change. 

5.2.4.6  PA4.6  -  Evaluate  Design  for  Adequacy/Relevance  with  Respect  to  Requirements 

In  this  Process  Activity,  the  stakeholders  verify  whether  the  conceptual  model  design  meets  the  criteria  that 
are  manifest  in  the  conceptual  model  requirements.  Their  criteria  are  also  part  of  the  V&V  argumentation 
framework.  Typical  topics  that  must  be  specified  and  transformed  into  criteria  are  whether  all  views  needed 
by  the  stakeholders  are  available  and  for  each  view  whether  the  chosen  formalism  is  capable  of  expressing  the 
conceptual  model.  For  example,  there  must  be  one  or  more  model  kinds  that  present  and  completely  cover  the 
user’s  view.  There  must  also  be  one  or  more  views  that  present  and  completely  cover  the  designer’s  view. 

Listed  below  are  the  points  of  emphasis: 

•  It  is  not  necessary  to  wait  until  the  requirements  are  perfect  before  starting  to  design  the  conceptual 
model  and  it  is  not  forbidden  to  start  building  the  actual  conceptual  model  to  express  the  intent  as  the 
effort  progresses  in  order  to  help  progressing  through  the  requirements.  This  conceptual  modeling 
guidance  supports  the  creative  process  of  evolving  a  conceptual  model.  Trying  to  express  in  building 
a  preliminary  conceptual  model  is  part  of  the  iterative  design. 

•  The  conceptual  model  design  always  starts  with  an  informal  mean  to  express  ideas.  It  evolves  each 
time  the  mean  induces  ambiguity  or  constrains  what  needs  to  be  expressed.  The  evolution  is  from  less 
formal  to  more  formal.  The  process  of  evolving  a  conceptual  model  design  is  essential  to  the 
stakeholders  self  and  mutual  understanding.  The  conceptual  model  design  process  is  a  learning 
process;  the  process  of  becoming  aware  of  self  and  others’  understanding,  bias  and  expectations. 
There  is  more  to  it  than  just  what  is  recorded  in  the  actual  conceptual  model  artefact.  The  journey 
serves  as  much  as  the  end  destination. 

•  It  is  important  to  be  intentionally  selective  on  the  conceptual  model  components  (conceptual 
primitives,  model  kinds,  views,  formalisms,  and  notations)  to  reduce  the  risk  of  uninformed  use  of 
components. 

•  The  producers  have  the  discretionary  choice  of  conceptual  model  components,  but  they  also  have  the 
responsibility  to  justify  their  choice. 
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•  Because  the  conceptual  model  components  are  tightly  entangled,  this  five-unknown  system  of 
equations  can  only  be  solved  iteratively  until  the  requirements  are  all  satisfied  and  the  design  is 
reconciled  in  a  coherent  conceptual  model  component  combination.  It  is  advised  to  select  conceptual 
model  components  and  try  building  a  preliminary  conceptual  model.  If  the  design  becomes  too 
constraining,  it  is  time  to  redesign  toward  another  level  of  conceptual  model  characteristics. 

•  Specific  modeling  tools  are  helpful  to  design  coherent  conceptual  model  component  combinations. 
It  is  not  rare  that  the  tool  influences  the  design  choices,  which  may  affect  the  conceptual  model 
characteristics. 

•  It  is  important  to  remind  that  although  the  coherence  of  the  conceptual  model  component  combination 
is  a  necessary  condition,  the  conceptual  model  design  must  be  driven  by  the  requirements,  mostly 
stakeholders’  representation  requirements  and  conceptual  model  characteristics  requirements. 

•  It  is  important  to  document  which  requirements  cannot  be  met  within  the  constraints  of  the  design 
and  to  update  the  effective  conceptual  model  characteristics  accordingly  in  the  conceptual  model 
Meta  data. 

•  It  is  not  rare  to  feel  the  need  to  invent  new  conceptual  model  components  when  encountering 
expressiveness  limitations.  This  is  why  general  modeling  languages  allow  creating  profiles 
(e.g.,  UML,  SysML)  and  common  standards  emerge  from  specific  communities.  It  is  useful  to  look  at 
related  community  conceptual  models,  as  a  reference  since  they  are  likely  to  suit  similar  needs. 
It  is  not  wrong  to  invent  new  conceptual  model  components  when  nothing  satisfying  already  exists. 
It  would  be  useful  to  develop  the  body  of  knowledge  to  determine  the  common  design  patterns 
(appropriate  conceptual  model  component  combinations)  typically  used  by  the  M&S  community. 

5.2.5  Process  Phase  5  Guidance  -  Build  Conceptual  Model 

The  Conceptual  model  development  Process  Phase  described  here  is  the  final  stage  of  the  five-step  process 
and  entails  the  completion  of  the  subject  conceptual  model  by  means  of  its  compilation  and  qualification  for 
its  intended  use. 

The  components  of  Phase  5  (PP5)  Process  Activities,  their  inputs,  and  resulting  products  are  indicated  in 
diagram  of  Figure  5-9  below. 
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act  P P 5  Activity  Diagram:  Build  CM 


Figure  5-9:  PP5  Activity  Diagram:  Build  Conceptual  Model  Indicating 
Process  Activities,  Process  Flow,  and  Artefact  Generation. 

Depending  primarily  on  the  results  of  proceeding  activities  including  work-products  (i.e.,  P3.1  -  Validated 
Knowledge  and  P4.1  -  Conceptual  Model  Design),  and  resulting  in  a  single  work-product  result  (i.e.,  P5.1  - 
Conceptual  Model);  Phase  5  consists  of  five  (5)  Process  Activities  (PA5.1  through  PA5.5)  whose  contextual 
circumstances,  execution,  and  consequent  results  together  with  inter  process  flows  will  be  elaborated  in  the 
commentary  that  follows  and  in  detailed  formal  specification  in  Annex  G,  Tables  G-23  through  G-28. 

Some  guidance  relevant  to  the  entire  PP5  -  Conceptual  Model  development  phase  includes  the  following 
elements  considered  prudent  for  any  such  product  build  effort: 

•  Confirm  entrance  criteria  are  satisfied  and  that  all  necessary  resources  are  likely  to  be  available  in  time. 

•  Establish  Group  composition,  roles  and  responsibilities. 
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•  Establish  expectations  for  the  execution  of  all  Process  Activity  elements.  Plan  effort  and  manage  to 
resources,  schedule,  and  product  deliverables. 

•  Confirm  exit  criteria  with  conceptual  model  product  customer/user. 

5.2.5.1  PA5.1  -  Populate  the  Conceptual  Model  Using  the  Chosen  Primitives,  Model  Kinds, 

Formalism,  and  Notation 

Several  considerations  relevant  to  the  execution  of  PA5.1  relate  to:  input  assets,  preparation  for  effort 
execution,  conduct  of  the  activity  itself,  and  the  nature  of  resulting  effort. 

Overall  program  management  agent  for  conceptual  model  effort  is  presumed  to  provide: 

•  A  full  specification  of  characteristics  of  an  acceptable  conceptual  model  product;  and 

•  A  complete  set  of  validated  knowledge  of  both  the  mission  space  and  the  simulation  space. 

Nevertheless,  conceptual  model  build  Task  Group  should  be  prepared  to  communicate  liberally  with  Process 
Phase  3  and  4  execution  agents  to  request  clarification  of  information  provided  in  work-products  P3.1  and 
P4.1  and  to  request  additional  information  determined  necessary  to  complete  the  model  specification  as  build 
population  proceeds. 

In  preparation  for  formal  task  activity,  anticipation  of  circumstances  likely  to  arise  during  the  effort  is  prudent. 
Building  of  a  conceptual  model  entails  a  variety  of  determinations  that  may  not  be  fully  prescribed  by  design 
guidance  but  which  are  likely  to  affect  the  efficiency  and  quality  of  conceptual  model  product.  In  each  of 
these  cases,  provisional  determinations  by  the  conceptual  model  build  Group  are  recommended. 

Build  strategy  refers  to  the  election  of  style  of  operation  by  the  Group,  election  of  alternative  design  options 
not  otherwise  bound  by  requirements,  and  establishing  such  stylistic  conventions  as  may  facilitate  cooperation 
and  efficiency  of  the  Group.  Build  versions  may  be  spiral  so  that  a  succession  of  products  is  generated 
progressively  converging  on  the  desired  result.  Alternatively,  parallelization  techniques  such  as  partitioning 
the  mission  space,  allocating  model  constructs  (i.e.,  primitives  or  model  kinds)  to  Group  members  of  the 
group  may  be  convenient. 

Election  of  alternative  options  for  Primitives,  Model  kinds,  Formalisms  and  Notation  which  may  persist, 
consistent  with  P4.1  -  Conceptual  Model  Design  specified  constraints  may  be  necessary.  These  determinations 
and  such  style  conventions  to  be  shared  across  the  Group  should  be  established  by  consensus  before 
significant  build  composition  effort  is  begun.  Checking  the  implications  of  such  determinations  during  first 
spiral  reviews  will  reassure  the  Group  of  the  wisdom  of  its  choices. 

Prefatory  interpretation  of  sufficiency  criteria  for  the  expected  product,  cast  in  terms  of  easily  observable  and 
confirmable  product  characteristics  and  evidently  correlated  to  requirements  specification  elements  will 
provide  insurance  against  shortfalls  in  product  quality  in  areas  such  as  detail  and  completeness  (scope, 
entities,  entity-attribute  and  entity-relationships)  as  specified. 

Selection  and  prompt  access  to  sufficient  tools  is  prerequisite  to  start  of  work.  Selection  of  such  tools  should 
be  made  carefully  with  consideration  for: 

•  Familiarity  and  competence  of  Task  Group; 

•  Power  to  meet  conceptual  design  capture  and  specification;  and 

•  Facility  to  generate  views  and  published  data  products  acceptable  to  customer  user  stakeholders. 
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Finally,  establishment  of  Product  Document  management  process  and  information  storage  and  retrieval 
sufficient  to  contain  the  evolving  conceptual  model  work-product,  control  of  its  authoritative  configuration 
and  containing  commentary  on  tactical  decisions  -  just  as  is  prudent  for  requirements  or  code  management 
under  other  circumstances. 

During  execution,  conduct  of  Group  reviews  of  work  progress,  product  convergence  according  to  build 
strategies,  and  product  quality  should  compliment  normal  program  reviews  and  control  mechanisms. 
Cultivation  of  consistency  of  vision  across  the  conceptual  model  build  Group  is  a  powerful  mechanism  to 
maintain  consistency  of  product,  and  collaboration  among  Group  members. 

Work-product  capture  in  tool  consistent  with  Model  Design  guidance  in  form  suitable  for  use  as  publication  or 
transmission  of  database  as  Product  P5.1.  For  this  purpose,  preliminary  coordination  with  Stakeholder 
recipient  is  prudent. 

5.2.5.2  PA5.2  -  Create  the  Specified  Views 

Assuming  the  requirements  for  conceptual  model  design  are  satisfied,  and  tools  that  sufficiently  articulate  and 
powerful,  the  generation,  capture,  and  publication  into  document  or  database  archive  under  configurable 
control  should  be  straightforward.  In  order  not  to  be  disappointed  in  this  expectation,  view  generation  should 
be  included  in  product  reviews  during  PA5. 1 . 

5.2.5.3  PA5.3  -  Verify  Conceptual  Model  Consistency  with  Respect  to  Conceptual  Model  Design 

The  practice  of  system,  software,  or  simulation  verification  is  of  course  too  extensive  in  its  scope  and  detail 
and  too  myriad  in  its  alternative  strategies,  tactics  and  techniques  to  be  specified  here.  With  respect  to  the 
range  of  options  available  for  verification  of  the  preliminary  conceptual  model,  the  most  important 
considerations  are  consistency,  and  sufficiency  -  otherwise  wide  discretion  is  allowed  to  the  conceptual  model 
build  group  commensurate  with  ‘good  practice’  contingent  that  such  process  as  is  elected  is  declared  and 
documented  together  with  the  results  of  its  execution. 

Sufficiency  of  verification  consists  in  a  complete,  documented,  persistent,  and  traceable  confirmation  that  all 
the  attributes  required  by  the  conceptual  model  design  of  P4.1  are  present  in  the  subject  conceptual  model. 
Naturally  deliberate  and  professional  requirements  management  beginning  with  conceptual  model  design  and 
proceeding  through  the  process  of  model  build  is  desired  in  avoiding  (or,  alternatively  in  detecting)  such 
errors  of  omission. 

Consistency  in  verification  entails  that  attributes  of  the  Conceptual  Model  are  in  fact  self-consistent 
(presumably  in  accordance  with  Conceptual  Model  Design)  and  that,  in  particular,  no  pathological  attributes 
of  the  Conceptual  Model  not  addressed  in  the  Design  are  present  that  will  interfere  with  the  acceptability  of 
the  conceptual  model  in  supporting  its  intended  use  and  in  meeting  the  need  for  which  it  was  conceived  and 
created.  Such  errors  of  commission  are  more  difficult  to  identify  without  a  consistent  representational  schema 
in  the  design,  conscientious  attention  to  build  discipline,  and  thorough  testing  and  customer  use.  Execution  or 
inspection  of  the  conceptual  model  in  representation  of  use  cases  that  may  have  been  used  in  its  design  as  well 
as  with  such  cases  that  were  not  used  in  its  design  will  likely  be  helpful. 

5.2.5.4  PA5.4  -  Validate  Conceptual  Model  with  Respect  to  Mission  Space  and  Simulation 
Space  Knowledge 

See  above,  recognizing  the  distinction  between  verification  and  validation,  and  interpreting  the  above  in 
relation  to  the  appropriate  referent  -  that  is,  Validated  Knowledge  of  Product  P3.1. 
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5.2.5.5  PA5.5  -  Ensure  Acceptance  of  Conceptual  Model  by  Authorized  Stakeholder 

Whereas  verification  and  validation  are  technical  determinations  of  goodness  of  fit  or  similarity  between 
artefact  (here  a  conceptual  model)  and  one  or  another  referent  (here  design  requirements,  and  Validated 
Knowledge  respectively);  accreditation  is  an  administrative  decision  regarding  the  degree  to  which  an  asset 
(here  the  conceptual  model)  is  acceptable  for  its  intended  use.  On  this  account,  accreditation  processes  entail 
articulate  collaboration  between  the  accreditation  agent  stakeholder  and  the  proponent  of  the  asset  in  question. 
Several  considerations  pertain  to  this  circumstance. 

First  of  all,  unambiguous  identification  and  acquiescence  of  the  identity  of  the  accreditation  agent  is 
necessary.  If  the  authoritative  accreditation  agent  (or  agents)  is  not  clearly  identified,  due,  for  instance,  to  the 
relatively  large  number  of  agents  with  a  significant  ‘stake’  in  the  conceptual  model,  an  inefficient  decision 
process  is  to  be  expected  at  best.  Note  that  multiple  accreditation  agents  for  alternative  intended  uses  are  not 
uncommon  for  either  simulations  or  conceptual  models. 

Clarity  of  agreement  on  intended  uses  and  re-confirmation  of  accreditation  exit  criteria  in  advance  of  the 
accreditation  application  is  prudent  if  only  to  remove  inconsistency  between  acceptability  of  the  conceptual 
model  asset  due  to  migration  or  evolution  of  the  use  or  changes  in  staff  appointees. 

It  is  incumbent  upon  the  conceptual  model  build  agent  to  have  designed  and  execute  factory  acceptance  tests 
and  if  desired  user  delivery  tests  whose  results  have  been  suitably  documented,  interpreted  and  reported  in 
anticipation  of  the  preparation  of  submission  of  accreditation  request.  Coordination  of  accreditation  reviews; 
support  of  the  accreditation  decision  process  itself;  documentation  of  the  consequences  and  its  delivery  with 
the  completed  Product  P5.1  prepared  in  compliance  with  associated  guidance  completes  PA5.5,  PP5  and 
conceptual  model  development. 


5.3  CONCEPTUAL  MODELING  PROCESS  CONCLUSION 

In  preceding  text,  a  linearized  account  of  recommended  best-practice  guidance  for  conceptual  model 
development  and  management  process  is  provided.  That  account  is  intended  to  be  interpreted  together  with 
the  more  terse  but  systematic  specification  provided  in  Annex  G  as  constituting  recommended  best-practice 
conceptual  modeling  process.  Every  effort  was  made  by  the  Task  Group  to  produce  necessary  and  sufficient 
guidance;  in  forms  that  are  comprehensible,  consistent,  and  sufficient  for  guidance  of  practice  throughout  the 
conceptual  modeling  process  and  practically;  while  leveraging  the  minimal  sufficient  binding  on  the 
conceptual  modeling  practitioner  in  favor  of  allowing  liberal  elective  of  style,  an  convention  commensurate 
with  the  challenge  of  the  effort  and  the  cultural,  technical  and  business  practice  constraints  of  the  enterprise 
environment  in  which  effort  is  effected. 
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Chapter  6  -  CONCEPTUAL  MODEL  PRODUCT  GUIDANCE 

Having  addressed  in  Chapter  5  and  its  associated  Annex  G  the  process  intended  by  the  MSG-058  Task  Group 
to  be  executed  by  the  “M&S  Conceptual  Model  Development  Practitioner”  agent.  We  proceed  to  discuss  the 
expected  results  of  completion  of  the  “Conceptual  Modeling  Best-Practice  Development  Process”,  namely  the 
Conceptual  Model  itself 


6.1  PRODUCT  GUIDANCE  INTRODUCTION 

This  chapter  provides  the  MSG-058  Task  Group’s  “Best-Practice  Guidance  Specification  (BPGS)”  for  the 
“Conceptual  Model”  Product  as  indicated  in  Figure  3-4.  These  products  include  the  conceptual  model  itself,  as 
well  as  intermediate  documents  produced  in  the  course  of  following  the  conceptual  model  development  process. 
The  intermediate  products  are  critical  to  document  and  transfer  information  from  one  Process  Phase  to  the 
next,  and  are  also  very  valuable  references  for  later  simulation  development,  and  for  conceptual  model 
management  throughout  the  life  cycle,  including  VV&A. 

This  guidance  details  the  intents  and  ideas  behind  these  products  and  how  they  relate  to  different  phases  of  the 
conceptual  model  development  process.  It  defines  the  main  products  the  process  should  generate,  what  ideas, 
views  and  information  should  be  contained  in  each  of  them,  their  structure  and  their  format. 

The  complete  set  of  products  associated  with  conceptual  model  development  is  as  follows.  They  are  numbered 
with  respect  to  the  Process  Phase  within  which  each  one  is  developed: 

•  P 1 . 1  -  Stakeholder  Description. 

•  P 1 .2  -  Need  Statement. 

•  PI  .3  -  Constraints  and  Policies. 

•  P 1 .4  -  Conceptual  Model  Meta  Data. 

•  P2.1  -  Conceptual  Model  Requirements  Specification. 

•  P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs. 

•  P3 . 1  -  Validated  Knowledge. 

•  P4. 1  -  Conceptual  Model  Design. 

•  P5. 1  -  Conceptual  Model. 

Each  of  these  products  will  be  discussed  in  more  detail  in  subsequent  text,  and  technical  descriptions  of  each 
are  provided  in  Annex  H. 

This  product  set  has  been  designed  such  that  all  information  transfer  between  conceptual  model  development 
phases  is  contained  within  the  set  of  documents.  Further,  these  documents  are  the  input  and  output  of  specific 
phases.  This  relationship  is  shown  in  the  context  of  the  development  process  in  Figure  6-1. 
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Figure  6-1:  Conceptual  Model  Process  and  Product  Relationships. 


From  this  figure,  it  can  be  seen  that  Stakeholder  Descriptions,  Needs  Statement,  and  Constraints  and  Policies 
are  generated  in  the  1st  phase  and  provide  input  to  the  2nd  phase,  but  do  not  continue  to  influence  subsequent 
phases.  This  means  that  all  relevant  content  of  these  products  must  be  translated  into  the  Conceptual  Model 
Requirements  Specification  and  Conceptual  Model  Knowledge  Acquisition  Needs  documents  during  the 
2nd  phase.  Likewise,  the  Conceptual  Model  Requirement  Specification  must  be  translated  into  the  Conceptual 
Model  Design  in  the  4th  phase  to  provide  input  to  the  fifth  and  final  phase,  whereas  the  Conceptual  Model 
Knowledge  Acquisition  Needs  are  translated  into  Validated  Knowledge  in  the  3rd  phase  and  made  available 
directly  to  the  5th  phase.  Conceptual  Model  Meta  Data  is  modified  and  used  throughout  every  phase. 

Listed  below  are  the  points  of  emphasis: 

•  The  provided  products  are  provided  as  best-practice  in  conceptual  model  development. 

•  These  products  may  be  tailored  as  needed  by  the  developer. 

•  Product  development  will  be  as  allowed  by  the  previously  described  process. 

•  Intermediary  products  should  be  preserved  as  valuable  artefacts  for  the  conceptual  model  life  cycle. 
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6.2  CONCEPTUAL  MODEL  PRODUCT  DESCRIPTION 

In  the  sections  that  follow,  discussion  of  the  desired  conceptual  modeling  product  and  its  component  elements 
are  provided.  The  intention  of  the  text  is  to  provide  a  plausible  explanation  and  rationale  of  the  entire  work- 
product  expected  to  be  necessary  and  sufficient  to  constitute  a  military  simulation  conceptual  model. 

In  particular,  information  is  provided  that  is  intended  to  address: 

•  Motivation  for  conceptual  model  component  artefacts. 

•  Considerations  relevant  generation  of  specific  conceptual  model  components  not  wholly  addressed  in 
the  preceding  process  specification. 

•  Data-item  description  of  conceptual  model  components,  including  explication  of: 

•  Information  content  recommended  for  the  subject  data  component; 

•  Data  format  suggestions  for  syntactic  specification  of  information; 

•  Manifestation  in  forms  that  are  suitably  consistent,  manageable,  persistent,  accessible,  and  re-usable; 
and 

•  Relationships  among  conceptual  model  information  artefacts. 

•  Fundamental  utility,  special  value  with  respect  to  quality,  cost  effectiveness,  ‘ilities’,  etc. 

•  Special  sensitivities  associated  with  generation,  administration  and  use  of  conceptual  model  component 
elements. 

This  account  is  provided  as  a  complimentary  and  consistent  form  of  guidance  which,  when  taken  together  with 
the  systematically  tabular  guidance  specification  contained  in  Annex  H,  is  considered  necessary  and  sufficient 
to  inform  best-practice  results. 

6.2.1  Product  1.1  Guidance  -  Stakeholder  Description 

The  Stakeholder  Description  product  component  is  a  document-mapping  stakeholder  to  roles  and  responsibilities 
in  the  conceptual  modeling  effort  throughout  the  entire  enterprise  life  cycle.  The  purpose  of  this  product  is  to 
identify  the  stakeholders  of  a  particular  conceptual  modeling  development  effort  and  their  respective  roles  and 
responsibilities  to  enable  staffing/tasking  of  the  conceptual  modeling  development  effort,  derivation  of 
stakeholder-related  requirements  and  stakeholder-related  knowledge  needs,  and  identification  of  subject- 
matter  expertise  for  knowledge  acquisition,  capture,  administration,  and  use. 

At  a  minimum,  the  product  includes  relevant  conceptual  model  development  responsibilities  identified  and 
grouped  into  roles,  and  stakeholders  identified  organizationally,  mapped  to  responsibilities  and  roles. 
It  is  desirable  to  also  include  stakeholder  identities  by  name,  and  point  of  contact  information,  when  known. 
Stakeholder  candidate  classes  are  thoroughly  described  in  Section  4.3.3  of  this  document,  and  the  Process 
Activity  to  generate  this  product  is  described  in  Section  5. 2. 1.1. 

Stakeholder  role  specification  within  the  enterprise  is  indicated  in  the  Figure  6-2,  wherein  composition  of  role 
specifications  and  types  of  role  functions  are  generally  indicated,  (see  Lexicon/Glossary,  Annex  J  for  terminology 
definitions)  Naturally,  alternative  concepts  of  role  specification  are  admissible,  but  should  be  prescriptively 
defined  in  relevant  documentation  along  with  accompanying  role  descriptions. 
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Figure  6-2:  Components  of  a  Role  Specification  and  Relationships  to  Role  Functions. 

Information  content  suggested  as  minimally  sufficient  for  documentation  of  conceptual  modeling  roles 
actually  employed  within  the  enterprise  is  suggested  in  Figure  6-3.  Note  the  obvious  distinction  between  role 
specification  and  role-holder  agent  or  individual.  This  segregation  particularly  facilitates  the  establishment  of 
organizational  postures  for  the  conceptual  modeling  agents  with  the  enterprise  in  anticipation  of  or 
commensurate  with  appointment  of,  or  changes-to  particular  role-holder  assignments. 


^Name 

r 


Role  Title 


Enterprise  Title 

Role  Eligibility  Qualifications 


Role  Functional  Responsibility 


Contact  Information 

> 

Figure  6-3:  Suggested  Role  Specification  and  Stakeholder  Role  Assignment  Information  Taxonomy. 
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As  indicated  in  Section  4.3.3,  the  fact  of  the  usual  diversity  and  particular  nature  of  stakeholder  postures 
relative  to  conceptual  modeling  within  the  enterprise  is  a  matter  of  considerable  sensitivity.  Difficulties  arising 
from  failure  to  appreciate  the  existence,  necessity  and  inter-relationships  among  these  roles  commonly  afflict 
conceptual  modeling  efforts  and  denigrate  the  consequent  value  of  conceptual  model  products.  Systematic 
investment  in  stakeholder  role  specification  as  a  formal  part  of  the  conceptual  model  product  is  considered 
well  worth  its  relatively  modest  cost. 

6.2.2  Product  1.2  Guidance  -  Need  Statement 

The  Need  Statement  product  is  a  document  that  defines  the  intended  use  of  the  conceptual  model,  derived 
from  the  purpose  and  intended  use  of  the  M&S  within  the  expected  enterprise  environment.  This  product 
serves  as  the  source  from  which  to  generate  the  derived  set  of  conceptual  model  requirements  and  knowledge. 
The  Process  Activity  to  generate  this  product  is  described  in  Section  5. 2. 2.4. 

Publication  of  conceptual  model  needs  statement  is  motivated  by  the  criticality  of  preservation  of  audit 
traceability  from  intended  use  of  prospective  simulation  implementations  through  expected  uses  of  the 
conceptual  model  itself  throughout  the  simulation  enterprise  life  cycle.  In  tracing  these  related  needs  and 
intended  uses,  it  is  important  to  consider  the  conceptual  model  and  the  consequent  simulation  generated  there¬ 
from  as  distinct  product  entities.  Sequentially,  the  need  for  the  simulation  typically  arises  first;  then,  the  need 
for  the  conceptual  model  to  support  the  life  cycle  of  that  simulation  is  made  manifest.  Thereafter,  conceptual 
model  requirements  may  be  generated  based  both  on  simulation  needs  and  other  potential  utility  of  the 
conceptual  model  in  the  enterprise  environment.  Conceptual  model  requirements  emerge  and  the  conceptual 
model  is  itself  developed  and  published.  Thereafter,  simulation  requirements  may  be  finalized,  manifesting 
components  of  the  conceptual  model  -  from  which  the  simulation  itself  is  developed.  While  this  sequence  of 
events  is  not  always  adhered  to,  and  while  spiral  or  concurrent  simulation  development  within  an  enterprise 
environment  often  admits  to  contemporaneous  conceptual  model  and  simulation  product  evolution;  the  value 
of  audit  traceability  of  the  respective  process  and  build  threads  by  means  of  maintenance  of  conceptual  model 
needs  statements  for  successive  block-builds  is  difficult  to  overestimate. 

For  purposes  of  reference  for  each  of  the  components  of  the  conceptual  model  product  suite,  the  canonical 
causal  sequence  of  ‘needs’,  ‘requirements’,  ‘design’  and  ‘implementation’  may  be  considered  applicable. 
The  Task  Group,  while  aware  of  this  taxonomy,  has  not  considered  it  necessary  to  address  each  stage  of 
maturity  evolution  for  each  component  product,  but  have,  instead,  selected  the  elements  of  such  a  matrix  that 
most  need  explication,  and  for  which  best  value  may  be  attained  for  their  explicit  inclusion  in  the  subject  best- 
practice.  In  future  guidance,  consideration  to  completion  of  this  best-practice-to-product-component  may  be 
found  to  deserve  exhaustive  coverage.  Meanwhile,  for  reference  to  the  entire  matrix  of  possibilities  as  well  as 
indication  of  matrix  loci  actually  treated  in  detail  in  the  best-practice  guidance,  the  following  table  is  offered. 
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Table  6-1 :  Array  of  Maturity  Stages  versus  Conceptual  Model  Suite  Component 
Product  Addressed  in  Detail  in  the  Subject  Best-Practice  Explication. 


DESCRIPTION 

NEED 

REQUIREMENTS 

DESIGN 

IMPLEMENTATION 

Stakeholders 

Section  6.2.1 

Product  1.1 

Section  6.2.2 

Product  1.2 

Policy 

Section  6.2.3 

Product  1.3 

Meta  Data 

Section  6.2.4 

Product  1.4 

Section  6.2.4 

Product  1.4 

Section  6.2.4 

Product  1.4 

Knowledge 

Section  6.2.6 

Product  2.2 

Section  6.2.7 

Product  3.1 

Model 

Section  6.2.5 

Product  2.1 

Section  6.2.8 

Product  4.1 

Section  6.2.9 

Product  5.1 

Conceptual  model  data-item  specification  is  may  be  liberally  adjusted  in  order  to  conform  to  enterprise 
conventions.  In  fact,  many  forms  of  needs  statements  are  available;  from  which  tailored  adaptations  can  serve 
for  conceptual  models.  As  usual,  what  is  imperative  is  that  for  any  given  conceptual  model  development 
within  any  given  enterprise  environment,  the  conceptual  model  needs  statement  specification  formulary 
should  be  prescriptively  agreed-upon  among  the  stakeholder  community  and  preserved  longitudinally  across 
successive  conceptual  model  and  simulation  block-build  cycles.  Practically,  sensitivity  to  the  simulation  - 
user’s  vernacular  and  preconceptions  are  recommended. 

6.2.3  Product  1.3  Guidance  -  Constraints  and  Policies 

The  creation  and  use  throughout  the  conceptual  modeling  process  of  an  information-product  documenting  the 
strategic  business-practice  rules-of-the-road,  manifest  as  operational  constraints,  policies  and  practices, 
is  motivated  by  the  need  for  conceptual  modeling  to  exist  as  a  component  of  the  overall  M&S  enterprise 
environment  in  which  it  is  conducted.  Such  operational  guidance  may  exist  pursuant  to:  organizational 
regulations;  technical  standards;  enterprise  conventions;  stakeholder  preferences;  or  contingency  conditions 
relating  to  availability  of  information,  staff  or  materiel  resources,  While  such  constraints  and  policies  are 
present  in  every  management  context,  their  being  made  explicit  and  their  being  acknowledged  by  the  entire 
conceptual  modeling  stakeholder  community  is  particularly  valuable  in  conduct  of  conceptual  modeling 
programs.  This  special  sensitivity  results  from  the  facts  that: 

•  Conceptual  modeling  is  poised  as  it  is  among  stakeholder  communities  (particularly  between 
simulation  users  and  simulation  developers); 

•  That  the  success  of  enterprise  wide  initiatives  such  as  re-use  and  interoperability  depend  so  strongly 
upon  the  deliberate  and  successful  completion  of  conceptual  modeling  efforts;  and 

•  That  conceptual  modeling  is  typically  not  administered  with  sufficient  rigor  to  forestall  the 
misapprehensions  the  can  so  easily  arise  in  early  phases  of  simulation  development  life  cycle. 

Naturally,  documentation  of  such  strategic  guidance  admits  to  any  of  a  variety  of  forms  of  capture;  and,  since 
there  is  little  precedent  for  such  practice,  some  liberty  is  expected  on  the  part  of  conceptual  modeling  agents  in 
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creating  useful  product  of  this  type.  In  general,  an  explicit  ‘living  document’  kept  under  configuration  control 
in  the  enterprise  collaboration  environment  and  available  to  all  stakeholders  for  reference  should  suffice. 

The  Process  Activity  to  generate  this  product  is  described  in  Sections  5.2. 1.3  and  5. 2. 1.4.  A  more  detailed 
technical  description  of  this  product  is  provided  in  Annex  H,  Table  H-4. 

6.2.4  Product  1.4  Guidance  -  Conceptual  Model  Meta  Data 

Meta  data  is  generally  used  to  describe  the  data  it  is  referring  to,  and  provides  information  about  a  certain 
item’s  content,  such  as:  means  of  creation,  purpose  of  the  data,  time  and  date  of  creation,  creator  of  data,  what 
standards  used,  etc.  The  Conceptual  Model  Meta  Data  will  address  a  conceptual  model,  acting  as  its  identifier. 
Conceptual  models  are  stored  in  a  conceptual  model  repository  for  future  use  together  with  Meta  data 
specifying  how  they  have  been  produced,  i.e.,  when,  where,  by  whom,  from  what,  using  what  tool,  and  so  on. 
This  Meta  data  is  necessary  to  ensure  traceability  and  reusability  of  the  Conceptual  Model.  As  shown  in 
Figure  6-4,  the  Conceptual  Model  Meta  Data  is  not  part  of  Conceptual  Model,  but  it  is  delivered  as  an  end- 
product  along  with  the  conceptual  model  itself. 


Conceptual 

Model 


Figure  6-4:  Conceptual  Model  Meta  Data  Must  Always  be  Attached  to  the  Conceptual  Model. 


The  main  role  of  a  Meta  data  template  is  to  facilitate  reusability.  Meta  data  provides  information  enabling 
inferences  to  be  drawn  regarding  their  reuse  potential  for  supporting  the  extension  and  creation  of  models  and 
simulations.  Thus,  it  is  important  to  include  a  minimum  but  sufficient  degree  of  descriptive  information  about 
the  conceptual  model  in  its  Meta  data.  An  abstract  view  of  the  Meta  data  part  of  the  conceptual  model 
template  is  presented  in  Figure  6-5. 
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Figure  6-5:  Conceptual  Model  Meta  Data. 

The  Meta  data  template  can  accommodate  a  number  of  meta  features  of  the  conceptual  model,  for  example: 
Name,  Type,  Version,  Modification  Date,  Security  Classification,  Release  Restriction,  Purpose,  Application 
Domain,  Description,  Use  Limitation,  Use  History,  V&V  Data  Elements,  Keyword,  Implementation 
Dependencies,  Point  Of  Contact  (POC),  Reference  and  Glyph. 

•  POC:  Holds  information  about  an  organization  or  a  person  having  a  particular  role  with  respect  to  the 
conceptual  model. 

•  Model  Identification:  Can  accommodate  information  related  to  the  identification  of  a  conceptual 
model  such  as:  Name,  Type,  Version,  Modification  Date,  Security  Classification,  Release  Restriction, 
Purpose,  Application  Domain,  Description,  and  Use  Limitation. 

•  Use  History:  Provides  a  description  of  where  this  conceptual  model  has  been  used. 
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•  Reference:  Specifies  a  pointer  to  additional  sources  of  information  such  as  locations  in  XML  documents 
and  references  to  ontologies  (both  domain  and  middle  level)  which  are  used  by  the  conceptual  model. 

•  Implementation  Dependencies:  Maintains  a  log  of  all  dependencies  determined  during  the  development 
of  this  conceptual  model,  such  as  domain  ontologies  or  any  other  new  concept  introduced  by  the 
process  during  the  implementation  of  this  conceptual  model. 

•  Key  Word:  Holds  information  about  the  key  words  of  this  conceptual  model  for  future  use.  It  helps 
users  in  searching  for  this  conceptual  model. 

•  Glyph:  Is  responsible  for  holding  the  image  of  conceptual  model,  which  can  be  used  to  visually 
represent  a  conceptual  model  in  a  tool  palette  or  a  web  repository. 

•  V&V  Data  Elements:  The  V&V  process  can  produce  an  enormous  amount  of  data.  These  data  are 
collected  under  a  label  called  V&V  Data  Elements  and  placed  in  the  product  “Conceptual  Model 
Meta  data”.  In  the  table  below  a  list  of  data  items  is  presented  together  with  the  Process  Activities 
where  that  data  is  produced. 


Table  6-2:  V&V  Data  Elements  in  the  Conceptual  Model  Meta  Data. 


Meta  Data  V&V  Data  Elements 

PA  That  Produces  V&V  Meta  Data 

V&V  Requirements  Specification  (VV&A  Intended  use, 
W&A  Requirement,  VV&A  Constraint) 

1.1,  1.4 

V&V  Precondition  Specification  (Conceptual  Model 
Intended  Use,  Conceptual  Model  Use  Risk,  Conceptual 
Model  Requirement,  Conceptual  Model  Constraint, 
Conceptual  Model  itself  if  available) 

1.3 

Conceptual  Model  System  of  Interest 

1.2,  3.4 

V&V  Experimental  Frame 

1.3,  1.4 

V&V  Goal  Network 

1.2,  2.1,  3.4, 4.3, 4.4, 4.5 

V&V  Results 

2.2,  3.6,  4.6,  5.3,  5.4 

V&V  Claim  Network 

5.5 

Acceptance  Recommendation 

5.5 

Table  6-2  shows  the  Meta  data  elements  and  the  Process  Activity  that  produces  the  Meta  data.  A  short  description 
of  each  element  in  the  V&V  Data  Elements  is  given  below: 

•  V&V  Requirements  Specification 

All  requirements  that  are  placed  upon  the  V&V  products  or  effort  to  be  delivered  and  restrictions 
placed  upon  their  realisation.  It  is  sub-divided  into: 

•  V&V  intended  use 

An  account  of  how  the  Stakeholders  intend  to  utilise  a  V&V  product(s)  or  effort. 
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•  V&V  requirements 

A  statement  of  necessary  attributes,  capabilities,  characteristics,  or  qualities  a  V&V  product  or 
effort  shall  possess  in  order  to  have  value  to  the  Stakeholders.  This  could  for  instance  be  a 
requirement  on  the  usage  of  specific  formats  or  templates  for  V&V  products. 

•  V&V  constraint 

The  constraints  placed  on  the  execution  of  the  V&V  effort. 

•  V&V  Precondition  Specification 

The  prerequisite  information  for  the  execution  of  a  V&V  project.  Many  of  the  items  in  this  specification 
can  be  in  the  form  of  references  to  other  products  produced  in  this  conceptual  modeling  guidance. 
The  following  V&V  preconditions  are  required  to  properly  execute  a  V&V  project: 

•  Conceptual  model  intended  use 

An  account  of  how  the  conceptual  model  stakeholders  intend  to  utilise  the  conceptual  model. 

•  Conceptual  model  use  risk 

An  account  of  a  risk  associated  to  the  (intended)  utilisation  of  a  conceptual  model. 

•  Conceptual  model  requirement 

A  statement  of  necessary  attributes,  capabilities,  characteristics,  or  qualities  a  conceptual  model 
shall  possess  in  order  to  have  value  to  the  stakeholders. 

•  Conceptual  model  constraint 

A  restriction  placed  upon  the  realisation  of  a  conceptual  model. 

•  Conceptual  model  itself  if  (parts  of  it)  are  already  available. 

•  Conceptual  Model  System  of  Interest 

The  Conceptual  Model  System  of  Interest  specifies  the  referent  system,  which  is  usually  a  part  of  the 
real  world.  This  information  can  be  in  the  form  of  references  to  product  P3.1  -  Validated  Knowledge. 

•  V&V  Experimental  Frame 

The  V&V  Experimental  Frame  indicates  how  the  conceptual  model  is  to  be  evaluated  in  order  to 
obtain  results  that  can  be  used  as  evidence  for  criteria. 

•  V&V  Goal  Network 

The  V&V  Goal  Network  structure  provides  the  technical  vehicle  to  systematically  develop  a  set  of 
precise  and  well-argued  criteria  and  how  evidence  for  their  support  can  be  obtained.  Criteria  specify 
from  the  Stakeholders  perspective  a  set  of  requirements  that,  when  proven  properly,  result  into  a 
positive  acceptance  recommendation  for  the  conceptual  model  and  its  deployment. 

•  V&V  Results 

The  collection  of  obtained  V&V  data  that  are  used  as  foundation  to  build  evidence  for  the  criteria. 

•  V&V  Claim  Network 

The  V&V  Claim  Network  structure  provides  the  technical  vehicle  to  systematically  develop  a  well- 
argued  set  of  items  of  evidence  and  acceptance  claims.  These  acceptance  claims  are  a  declaration  of 
an  assertion  for  the  conceptual  model  and  its  deployment  on  whether  or  to  what  extent  its  results  can 
effectively  be  utilized  (i.e.,  value)  with  acceptable  consequences  (i.e.,  cost  and  use  risk). 
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•  Acceptance  Recommendation 

The  Acceptance  Recommendation  is  a  Stakeholders  oriented  presentation  of  the  V&V  claim  network 
and  other  relevant  V&V  project  information,  which  together  comprise  all  the  pieces  of  information 
needed  for  an  adequate  acceptance  decision-making  on  the  conceptual  model  and  its  deployment. 

6.2.5  Product  2.1  Guidance  -  Conceptual  Model  Requirements 

For  purposes  of  the  present  document,  a  specific  and  very  significant  distinction  is  made  between  ‘wants’  and 
‘needs’  on  the  one  hand  and  ‘requirements’  on  the  other.  The  rationale  for  that  distinction  illustrates  the 
motivation  for  specification  of  Conceptual  Model  Requirements  as  a  necessary  component  of  a  conceptual 
model  product  suite.  Whereas  formal  definitions  for  these  terms  are  provided  in  the  glossary,  the  fundamental 
distinction  has  to  do  with  the  relationship  of  these  terms  to  stakeholders  in  the  first  place  and  the  conceptual 
model  design  and  implementation  on  the  other.  So,  for  instance,  a  ‘want’  or  ‘need’  is  related  to  the  state  of 
expectation  or  intention  of  one  or  another  of  the  stakeholders.  Individually  or  collectively,  stakeholders  may 
have  anticipatory  preferences  for  that  which  is  produced  as  the  conceptual  model  proper  based  on  their 
intended  use  for  it  in  context  of  their  role  within  the  enterprise.  Thus,  wants  and  needs  as  discussed  in  Section 
6.2.2  (Product  1.2  Guidance  -  Need  Statement)  above  are  proximate  to  stakeholders’  preferences  and  may, 
or  may  not,  be  wholly  self-consistent,  complete,  or  informative  as  a  basis  for  creating  or  judging  the 
sufficiency  of  the  conceptual  model  artifact  per  se.  Wants  and  needs  in  this  view  are  desiderata.  In  the  same 
vein,  a  ‘requirement’  is  related  to  the  necessary  and  sufficient  attributes  of  the  conceptual  model  as  determined 
appropriate  for  the  enterprise  at  large.  Requirements  both  prescribe  and  proscribe  the  characteristics  of  the 
conceptual  model  which,  if  present,  guarantee  the  model  to  be  adequate  for  its  several  intended  uses.  As  such, 
requirements  must  be  monolithic  within  the  enterprise  and  must  manifest  the  potentially  disparate 
stakeholders’  wants  and  needs  in  positive-definite,  observable  form.  As  in  any  systems  engineering  or  product 
development  life  cycle,  stakeholders’  wants  and  needs  are  transposed  into  product  attribute  requirements  in 
accordance  with  the  product  life-cycle  management  strategies  (such  as  waterfall,  spiral,  etc.).  Discriminating 
between  needs  and  requirements  is  considered  best-practice  in  conceptual  model  development;  and 
documenting  each  separately,  while  preserving  audit  traceability  between  the  two  guarantees  the  appropriate 
causal  influence  of  stakeholders  needs  upon  requirements  and  consequently  (and  subsequently)  upon 
conceptual  model  artifact  qualities. 

Specification  of  requirements,  therefore,  is  useful  in  guiding  the  conceptual  model  design  and  implementation 
agents.  Published  requirements  serve  as  a  basis  for  evaluation  of  the  quality  of  the  resulting  conceptual  model 
quality  as  built.  Preservation  of  requirements  as  a  formal  component  product  of  the  conceptual  modeling 
process  guarantees  that  causal  dependencies  of  design  upon  stakeholders  needs  may  be  understood  in  the 
event  of  conceptual  model  product  evolution,  re-use,  or  expected  interoperability  with  other  such  models. 

Expression  of  requirements  is,  in  context  of  these  best-practice  recommendations,  left  materially  to  the 
discretion  of  the  requirements  development  and  documentation  agent  within  the  enterprise.  Observations 
relevant  to  alternative  expressional  modes  together  with  the  identification  of  some  determinative  factors  for 
choosing  particular  forms  of  expression  from  within  those  modes  are  intended  to  be  suggestive  rather  than 
prescriptive. 

Conceptual  model  requirements  are  certainly  an  information  product  whose  function  is  to  provide  a  necessary 
if  not  positively  sufficient  binding  upon  the  characteristics  of  the  desired  conceptual  model  proper.  As  such, 
the  scope  of  requirements  is  expected  to  extend  at  least  across  the  static  and  dynamic  set  of  observable 
attributes  of  conceptual  models  proper  (see  Section  4.4.2  Conceptual  Model  Characteristics).  Requirements 
‘Characteristics’  -  (see  Figure  4-4  Conceptual  Model  Characteristics);  such  as  scope,  quality,  utility,  formality, 
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abstractness,  consistency  and  special  value  with  respect  to  quality,  cost  effectiveness,  ‘-ilities’,  etc.; 
are  expected  to  be  included  in  the  requirements  regime.  Note  that  the  ‘observability’  of  required 
characteristics  documented  is  significant  insofar  as  the  confirmation  by  observation  of  the  values  of  those 
characteristics  as  manifest  in  the  conceptual  model  product  with  the  values  proscribed  in  requirements 
specifications  will  constitute  much  of  the  verification  of  that  conceptual  model  product.  There  are  a  few 
special  sensitivities  in  requirements  documentation  that  associated  with  generation,  administration  and  use  of 
conceptual  model  component  elements.  In  particular,  the  conceptual  model  stakeholder  team  should  be  aware 
of  completeness  challenges  associated  with  the  relevant  generation  of  specific  conceptual  model  components 
not  wholly  addressed  in  the  preceding  process  specification. 

As  an  information  product,  requirements  specifications  should  be  systematic  with  respect  to  representational 
schema  elected  for  use  within  the  enterprise.  Such  elective,  but  necessary  conventional  determinations  may 
include  data-item  description  of  conceptual  model  components,  including  explication  of: 

•  Information  content; 

•  Form  of  requirements  specification  -  Manifestation  in  forms  that  are  suitably  consistent,  manageable, 
persistent,  accessible,  and  re-usable; 

•  Relationships  among  conceptual  model  information  artefacts;  and 

•  Data  format. 

In  the  same  way  that  information  schemas  may  be  left  to  the  discretion  of  the  conceptual  model  requirements 
management  agent  and  contingent  upon  enterprise  stylistics  or  conventional  standard  the  choice  of  information 
management  artefacts,  e.g.,  classical  textual,  database,  or  related  forms  of  expressions,  and  the  choice  of 
CASE/COTS  tools  whereby  to  facilitate  the  generation,  publication,  reconciliation,  valuation  storage,  retrieval, 
and  re-use  are  considered  discretionary  just  in  case  such  determinations  are  explicit,  documented  as  intended 
practice  within  the  enterprise  environment,  and  complied  with  by  enterprise  stakeholders. 

Finally,  requirements  are  intended  to  have  the  logical  standing  of  imperatives  or  ‘shalls’  within  the  enterprise. 
Compliance  to  requirements  specifications  is  expected  to  be  explicit,  complete  and  auditably  traceable, 
contingent,  of  course,  that  mechanisms  exist  within  the  enterprise  for  prompt,  systematic,  and  convergent 
identification,  documentation  resolution,  and  identification  of  exceptions  to  published  requirements. 


6.2.6  Product  2.2  Guidance  -  Conceptual  Model  Knowledge  Acquisition  Needs 

The  purpose  of  this  product  component  is  to  document  and  to  communicate  to  the  conceptual  Model  producer 
what  knowledge  must  be  acquired  in  order  to  design  and  build  a  conceptual  model  that  will  serve  its  intended 
purpose.  Conceptual  model  knowledge  acquisition  needs  describe  the  scope  and  level  of  detail  of  knowledge 
needed  by  the  Conceptual  Model  developer  to  produce  a  conceptual  model  satisfying  the  client’s  need 
statement.  Conceptual  model  knowledge  acquisition  needs  guide  the  conceptual  model  developer  in  collecting 
the  necessary  knowledge  and  limit  knowledge  acquisition  to  the  minimum  sufficient  knowledge  set. 

Given  that  the  establishment  of  the  context  within  which  the  bulk  of  direct  conceptual  model  population  will 
occur,  the  following  effort  will  generate  information  to  be  contained  in  the  subject  data  product: 

•  Analyze  the  requirement  specification  in  order  to  derive  knowledge  needs. 

•  Document  knowledge  needs.  Information  content  of  this  product  describe: 
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•  The  entities  and  activities  in  the  mission  space  the  modeler  must  understand  in  order  to  represent 
them  correctly  and  with  appropriate  detail;  and 

•  The  simulation  technique,  tools  and  legacy  assets  the  modeler  must  understand  in  order  to 
represent  implementation  requirements  and  constraints  correctly. 

Contingent  review  the  conceptual  model  requirement  specification  in  order  to  identify  knowledge  needed  for 
developing  a  conceptual  model  with  sufficient  fidelity  to  satisfy  its  purpose;  information  covering  the  following 
domains  for  which  specific  needs  exist  will  be  specified: 

•  Technologies  applied  in  mission  space  entities  and  their  capabilities  and  limitations. 

•  Physical  theories  underpinning  these  technologies. 

•  Military  tactics,  techniques  and  procedures. 

•  Candidate  simulation  technologies. 

•  Legacy  simulation  models  and  their  capabilities  and  limitations. 

Criteria  for  sufficiency  of  the  subject  product  include  an  exhaustive  list  of  knowledge  elements  needed  to 
design  and  build  the  desired  conceptual  model  as  has  been  documented  in  P2.2. 

6.2.7  Product  3.1  Guidance  -  Validated  Knowledge 

Validated  knowledge  constitutes  the  authoritative  information  that  is  available,  necessary,  and  sufficient  for 
the  conceptual  model  development  agent  to  understand  the  mission  space  and  simulation  space  and  from 
which  to  construct  the  subject  simulation  conceptual  model. 

6.2.7.1  Overall 

Validated  Knowledge  is  a  product  of  the  NATO  conceptual  modeling  Process  Phase  3,  known  as  Acquire 
Conceptual  Model  Knowledge.  This  product  is  a  validated  piece  of  knowledge,  developed  in  response  to  an 
identified  need  and/or  requirement  from  the  previous  phases.  It  will  be  acquired  from  authoritative  knowledge 
sources,  and  will  then  be  structured,  documented,  and  validated  with  respect  to  that  authoritative  knowledge 
source.  This  product  will  be  the  sole  and  most  important  product  produced  during  Phase  3.  The  next  phase, 
Design  the  Conceptual  Model,  will  use  this  to  design  the  conceptual  model,  i.e.,  this  product  will  serve  as  the 
foundation  for  designing  and  building  the  final  conceptual  model. 

6.2.7.2  The  Generation  Process 

The  conceptual  modeling  process  is  iterative,  in  which  some  parts  and  steps  are  sometimes  conducted  in 
parallel.  By  the  end  of  every  phase,  one  or  more  products  are  generated  which  may  be  used  as  input  for  the 
next  or  another  coming  phase.  Moreover,  within  one  phase  some  activities  may  also  generate  one  or  more 
intermediate  products  which  may  be  used  as  input  for  the  following  activities  in  the  same  phase.  That  is  the 
case  for  Process  Phase  3,  where  the  end  result  will  be  P3.1  -  Validated  Knowledge. 

In  the  previous  phases,  the  needs  and  requirements  for  the  knowledge  were  completed  and  the  authoritative 
knowledge  sources  for  the  particular  knowledge  which  is  requested  were  identified.  But  of  course  before 
putting  any  effort  into  acquiring  the  required  knowledge,  one  should  search  in  some  existing  conceptual 
model  repository  to  look  for  knowledge  which  may  already  be  available  for  reuse.  So  the  next  activity  in  the 
process  will  start  looking  for  the  corresponding  reusable  knowledge  for  that  particular  conceptual  model 
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which  may  already  exist  in  an  existing  conceptual  models  repository,  knowledge  that  can  be  either  partly  or 
completely  usable  for  this  new  need.  If  not,  the  lack  of  knowledge  and  the  gaps  which  must  be  filled  are 
identified. 

As  previously  mentioned,  the  conceptual  modeling  Process  Phase  3  is  about  acquiring  sufficient  and  necessary 
knowledge  about  a  particular  conceptual  model  by  applying  knowledge  acquisition  methodologies.  These 
methodologies  and  the  corresponding  techniques  help  to  ensure  that  the  correct  and  necessary  data  is  gathered 
from  the  correct  sources.  When  data  is  obtained  (and  is  presumed  to  be  in  raw  text  format,  all  other  formats  of 
data,  such  as  voice,  video,  etc.,  can  also  be  converted  to  raw  text)  it  is  assumed  to  be  unstructured  and  the  first 
step  is  to  analyze  and  structure  it  for  further  use.  The  data  is  therefore  processed  by  knowledge  analysis  and 
formalization  methodologies  employing  the  appropriate  tools.  By  using  these  tools,  the  data  is  structured  and 
focused  according  to  some  world  view  (e.g.,  ontology).  Smaller  sections  of  this  structured  data  can  now  be 
called  knowledge  instances.  The  knowledge  instances  are  useful  for  some  purposes,  but  they  are  not  reusable 
since  they  are  specific  to  the  used  data  (e.g.,  scenario  data,  or  the  result  of  interviewing  one  specific  SME  for 
a  particular  case).  To  get  reusable  components,  modeling  tools  and  methodologies  must  be  applied  to  the 
knowledge  instances  in  order  to  get  more  abstract  and  reusable  components.  To  make  certain  that  no 
information  is  misinterpreted  the  ontologies  (as  a  knowledge  base)  are  necessary.  These  components  can  now 
be  called  knowledge  components  and  can,  with  the  aid  of  more  methodologies  and  tools,  be  composed  to  form 
one  or  more  conceptual  models.  All  of  these  products  (Scenario  Data,  Interview  Results,  Knowledge 
Instances,  Knowledge  Components,  Conceptual  Models,  etc.)  should  be  stored  in  a  conceptual  model  repository 
for  future  use,  together  with  Meta  data  specifying  how,  when,  where,  by  whom,  from  what,  using  what  tool, 
etc.,  they  have  been  produced.  This  Meta  data  is  necessary  to  ensure  traceability.  Now,  there  should  be 
enough  information  to  either  generate  a  domain  ontology  for  this  particular  mission  space  or  extend/update  an 
existing  one.  Finally  the  validity  of  the  acquired  knowledge,  with  respect  to  the  authoritative  knowledge 
sources,  will  be  reviewed  before  this  product  can  be  produced. 


6.2.13  The  Validation  Process 

The  last  activity  in  this  phase  of  the  conceptual  modeling  Process,  PA3.6  -  Review  Validity  of  Acquired 
Knowledge  with  respect  to  the  Authoritative  Knowledge  Sources,  discusses  and  examines  the  validity  of 
recently  created  knowledge  with  respect  to  authoritative  knowledge  sources,  and  is  through  that  guarantee  that 
the  end-product  can  be  said  to  live  up  to  the  requirements.  This  activity  may  be  initiated  as  soon  as  the  activity 
PA3.5  -  Generate/Extend  a  Domain  Ontology,  is  done  and  the  acquired  knowledge  is  ready  for  review. 

For  the  validation  of  the  conceptual  model,  it  is  necessary  to  determine  whether  all  the  abstractions  used  in 
modeling  are  suitable/sufficient  for  the  given  purpose  and  end-product  usage.  All  quality  requirements  must 
be  specified  in  the  V&V  goal  model  of  the  AF,  and  a  precise  description  must  be  available  of  what  evidence  is 
needed.  Part  of  that  description  is  what  data  must  be  “measured”  in  the  conceptual  model  and  a  description  of 
the  reference  data  to  which  it  is  to  be  compared.  Also  the  quality  of  the  “measurement”  and  the  quality  of  the 
reference  data  are  specified.  For  each  piece  of  required  evidence,  it  must  be  considered  if  the  available 
reference  data  is  of  sufficient  quality.  The  reference  data  may  measure  real-world  data,  theories, 
SME  opinions,  etc.  But  for  each  of  those  types  of  reference  data,  the  quality  must  be  considered. 

If  SME  is  used  as  reference  data  the  conceptual  model  will  be  reviewed  and  examined  (preferably  performed 
with  assistance  of  a  VV&A  agent)  by  that  SME,  whose  reality  has  been  captured  and  documented,  to  see  if  the 
documented  knowledge  is  correct  and  completely  represents  the  activity.  That  is  to  say,  examining  whether 
the  result  of  the  knowledge  acquisition  phase  is  acceptable  to  the  owner  of  the  mission  space.  An  ontology 
expert  may  also  examine  if  the  generation  or  integration  of  the  ontology  is  done  correctly. 
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When  the  acquired  knowledge  or  the  ontology  is  validated,  Phase  3  is  completed  and  the  Product  3.1  is 
considered  being  ready  for  use,  i.e.,  the  artefact  is  qualified  to  go  to  the  next  phase  of  conceptual  modeling 
process. 


6.2.7 .4  Significant  Inputs,  Tools,  Methods  and  Roles 

To  produce  P3.1  -  Validated  Knowledge,  some  inputs  are  required: 

•  The  Knowledge  Needs  and  the  Requirements  List  from  the  previous  phases. 

•  A  list  of  the  authoritative  knowledge  sources  for  the  required  knowledge  is  also  advantageous. 

•  An  existing  conceptual  model  repository  with  reusable  knowledge.  Also  domain  ontologies  in  a 
knowledge  base  are  very  much  appreciated  but  not  mandatory. 

This  product  is  a  result  of  a  knowledge  development  process  and  thus  support  of  appropriate  tools,  methods, 
and  techniques  from  the  knowledge  development  area  is  very  much  appreciated.  Such  things  could  include: 

•  Methodologies  for  acquisition  of  data,  information,  and  knowledge. 

•  Methodologies  for  documentation,  representation,  and  formatting  the  acquired  knowledge. 

•  Tools  for  knowledge  acquisition,  representation,  formalization,  etc. 

•  Tools  for  managing  and  maintaining  ontologies  as  well  as  ontology  reviewing  tools. 

•  V&V  methodologies,  e.g.,  GM-VV  as  well  as  V&V  tools. 

Some  of  the  roles  and  their  areas  of  responsibility  used  when  generating  this  important  product  have  been 
identified  as: 

•  Knowledge  engineer,  to  provide  experience  in  acquiring,  gathering  and  compiling  information; 

•  SME,  to  provide  the  domain  and  task  knowledge; 

•  Analysis  and  formatting  expert;  experienced  in  the  appropriate  formatting  analysis  method  and 
technique; 

•  Ontology  expert;  experienced  in  mapping  and  interpreting  information  held  in  the  ontology,  as  well  as 
being  skilled  in  how  to  further  develop  and  extend  ontologies;  and 

•  VV&A-agent  for  validating  the  result. 

6.2.8  Product  4.1  Guidance  -  Conceptual  Model  Design 

Just  as  in  text  Section  6.2.5  above,  the  Task  Group  felt  the  necessity  to  distinguish  with  particular  precision  the 
distinction  between  ‘needs’  and  ‘requirements’;  at  this  point  in  the  exposition,  we  feel  the  incumbent 
responsibility  to  distinguish  between  ‘requirement’  and  ‘design’.  Both  requirements  and  designed  presage  the 
artefact  (namely  the  conceptual  model  per  se )  itself.  They  are,  however,  individuated  in  several  ways  that  make 
the  creation  and  persistent  management  of  requirements  and  design(s)  separately  valuable  to  the  conceptual 
modeling  enterprise.  Definitions  such  as  are  provided  in  the  Glossary  appended  are  suggestive  of  these  salient 
distinctions;  but,  for  purposes  of  this  document  the  following  discriminates  are  cited  as  particularly  relevant: 

•  Requirements  generally  address  specific  attributes  of  the  subject  system;  while  designs  address 
collective/composite/holistic  characteristics. 
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•  Requirements  are  derived  (devolved)  from  user/stakeholder  needs;  while  design  strategies,  tactics  and 
features  are  generated  to  be  compliant  with  existing  requirements  -  in  this  phase  of  system  evolution, 
design  discretions  permitted  insofar  as  requirements  compliance  is  assured. 

•  Requirements  consist  primarily  in  attribute  specification;  while  designs,  while  respecting  required 
attributes  must  be  implementation  specific. 

•  Requirements  entail  necessary  conditions;  while  designs  entail  sufficient  conditions. 

•  Requirements  address  structure  and  functional  necessary  attributes;  while  designs  address  in  addition 
compositional  relationships  among  both  structure  and  functions. 

•  Requirements  are  insofar  as  possible  implementation  indifferent;  while  designs  are  of  necessity 
implementation  specific. 

•  Requirements  must  proscribe  prospective  systems  to  the  degree  that  they  are  sufficient  to  support 
some  prospective  design;  while  designs  must  be  sufficient  to  support  all  necessary  requirements. 

•  Requirements  serve  as  a  basis  for  user  verification;  while  Design  specifications  must  serve  as  a  basis 
for  construction  verification. 

•  Finally,  requirements  are  similar  to  the  Aristotelian  final  cause  or  telos,  e.g.,  ‘that  for  the  sake  of 
which’;  while  design  is  more  nearly  related  to  Aristotelian  material  cause  (e.g.,  ‘that  out  of  which’), 
and  formal  cause  (e.g.,  ‘the  form  ...  the  account  of  what  is  to  be’). 

Motivation  for  conceptual  model  design  -  as  for  any  system  design  artefact  -  is  to  establish  constraints  upon 
the  subject  product  that,  when  observed,  improve  the  fundamental  utility,  quality,  cost  effectiveness,  ‘ilities’, 
etc.,  of  the  work-product.  The  design  should  in  effect  bind  the  conceptual  model  product  in  such  a  way  as  to 
guarantee  accomplishment  of  requirements.  Product  design  should  be  sufficient  to  guide  and  control 
implementation  agents  possessing  a  clear  appreciation  of  the  enterprise  context  of  the  intended  product  to 
complete  a  satisfactory  product.  Design  should  contain  explicitly  or  by  inferential  implication  from  requirements, 
etc.,  everything  short  of  conceptual  model  instance  semantic  content.  That  information  is,  of  course,  contained 
in  mission  space  and  simulation  space  Meta  data.  Conceptual  model  product  design  should  constitute  a  plan  or 
scheme  conceived  in  the  mind  and  intended  for  subsequent  execution;  addressing:  architecture,  notational 
schemas,  data  formats,  and  documentary  tools.  Finally,  conceptual  model  design  may  contain  any  information 
considerations  relevant  to  the  generation  of  specific  conceptual  model  components  not  wholly  addressed  in 
the  preceding  process  specification. 

Naturally,  documentation  of  conceptual  model  design  admits  to  any  of  a  variety  of  forms  of  capture;  and, 
since  there  is  little  precedent  for  such  practice,  some  liberty  is  expected  on  the  part  of  conceptual  modeling 
agents  in  creating  useful  product  of  this  type.  In  general,  an  explicit  ‘living  document’  kept  under  configuration 
control  in  the  enterprise  collaboration  environment  and  available  to  all  stakeholders  for  reference  should  suffice. 

The  Process  Activity  to  generate  this  product  is  described  in  Section  5.2.4  as  Process  PP4.  A  more  detailed 
technical  description  of  this  product  is  provided  in  Annex  H,  Table  H-9. 

6.2.9  Product  5.1  Guidance  -  Conceptual  Model 

The  conceptual  model  per  se  is,  in  this  exposition,  the  final  component  of  the  conceptual  model  development 
process.  Having  proceeded  through  the  conceptual  model  development  process  described  in  Chapter  5  and 
detailed  in  the  process  specification  of  Annex  G,  and  having  generated  product  artefacts  above  described  in 
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this  chapter,  in  accordance  with  the  product  specification  of  Annex  H  there  remains  only  to  comment  upon  the 
populated  resulting  simulation  conceptual  model. 

The  conceptual  model  product  itself  is  clearly  the  conceptual  model  design,  populated  with  mission  space  and 
simulation  space  data  generated,  compiled  and  validated  in  preceding  tasks.  Seen  as  such  it  is  merely  the 
practical  compilation  of  information  previously  gathered  consistent  with  the  wants  and  needs  of  simulation 
stakeholders,  in  context  of  the  subject  simulation  enterprise  environment.  It  is,  therefore  one  -  if  the  last  - 
information  product  of  the  suite  of  artefacts  resulting  from  the  conceptual  modeling  effort.  Nevertheless, 
as  the  culmination  of  that  effort  it  is  distinctive  and  particularly  noteworthy. 

Just  as  the  conceptual  model  design  above  constitutes  the  descriptive  and  prescriptive  specification  of  the 
conceptual  model;  the  simulation  conceptual  model  itself,  constitutes  the  de  facto  design  of  the  resulting 
simulation’s  representation  capabilities  and  implementation  characteristics.  Insofar  as  the  conceptual  model 
has  been  generated  by  a  suitably  systematic  devolution  beginning  with  simulation  user  needs  and  proceeding 
through  collection  and  qualification  of  Meta  data,  specification  schema,  and  information  product  design 
stages,  it  manifests  the  fundamental  information  necessary  and  sufficient  for  the  creation  of  a  satisfactory 
simulation.  Insofar  as  the  conceptual  model  development  process  has  been  conducted  with  due  regard  to  the 
enterprise  context  in  which  such  simulations  are  to  be  developed  and  used,  it  establishes  a  sound  basis  for 
collaborative  business  practice  throughout  the  enterprise  and  over  its  practical  duration. 

The  Process  Activity  to  generate  this  product  is  described  in  Section  5.2.5  as  Process  PP5.  A  more  detailed 
technical  description  of  this  product  is  provided  in  Annex  H,  Table  H-10. 
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Chapter  7  -  CONCLUSIONS  AND  RECOMMENDATIONS 

This  best-practice  guidance  is  intended  to  lay  the  foundation  for  practical  and  effective  conceptual  model 
development,  to  serve  as  a  baseline  for  individual  enterprise  tailored  implementations,  and  to  set  the  vector  for 
future  standardization  and  conceptual  model  life-cycle  management. 

7.1  OBSERVATIONS  AND  INFERENCES 

Conceptual  modeling  begins,  most  often  unconsciously,  at  the  very  beginning  of  the  first  idea;  long  before  the 
official  conceptual  modeling  effort  starts.  Notes  and  drawings  scrawled  in  the  corner  of  a  napkin  already  begin 
the  abstraction  process,  and  in  doing  so,  provide  the  first  bias.  As  in  Heisenberg  Uncertainty,  where  a 
phenomenon  is  disturbed  as  soon  as  one  tries  to  measure  it,  the  referent  in  a  conceptual  model  is  distorted  as 
soon  as  one  tries  to  represent  it.  This  is  one  reason  so  many  simulation  frameworks  have  turned  out  to  be 
unusable  or  un-reusable  while  they  were  modeled  as  point  solutions  such  as  “red  against  blue”,  instead  of 
more  composable  structures,  such  as  “entities  and  interactions”.  The  conceptual  modeling  enterprise  does  not 
get  rid  of  these  biases,  as  much  as  it  makes  the  choosing  of  biases  deliberate  and  well  documented. 

The  conceptual  model  of  a  simulation  is  not  simulation  space  implementation  independent.  It  may  appear  to 
be  so,  without  any  specific  references  to  the  simulation  space,  but  the  decisions  that  were  made  during  the 
conceptual  model  design  inevitably  were  informed  by  the  underlying  need  for  a  simulation  capability  or  an 
enterprise  interest. 

Current  practice  in  simulation  development  rarely  includes  an  explicit  conceptual  modeling  effort.  This  fact 
was  the  primary  motivation  for  the  development  of  this  guidance.  But  study  of  ongoing  enterprises  has 
revealed  a  few  shining  examples  of  deliberate  conceptual  modeling  practices  that  are  encouraging  in  the 
commonality  of  their  underlying  principles,  even  as  they  took  varied  approaches  in  the  conduct  and 
description  of  their  efforts.  The  value  of  this  guidance  to  these  and  future  enterprises  is  the  provision  of  a 
broad  and  flexible  process  with  defined  products  which  can  be  mapped  against  current  approaches  and  future 
plans.  Common  terminology  can  also  be  derived  from  this  guidance  to  enable  better  communication  of 
concepts  between  enterprises. 

Once  the  community  is  able  to  produce  a  critical  mass  of  conceptual  model  products  from  a  diverse  set  of 
enterprises,  refining  best-practices  through  a  variety  of  experiences,  the  methods  of  standardization  and  reuse, 
along  with  evolution  towards  automation  and  machine  readability,  can  bring  about  substantial  efficiencies  in 
the  conceptual  model  and  M&S  development  and  their  respective  life-cycle  management  efforts. 


7.2  RECOMMENDATIONS 

The  following  comprise  the  recommendations  distilled  from  the  experience  of  the  MSG-058  Task  Group  and 
which  are  proffered  for  consideration  in  conducting  NATO  M&S  conceptual  modeling  activity  in  expected 
collaborative  enterprise  environments: 

•  NATO  Nations  should  adopt  this  guidance  as  best-practice  for  their  national  and  international  M&S 
efforts  to  enable  interoperability  and  reuse. 

•  The  modeling  and  simulation  community  should  take  this  opportunity  to  deliberately  incorporate 
conceptual  model  development  into  their  respective  M&S  development  processes,  based  on  the  best- 
practice  provided  in  this  guidance. 
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•  Each  enterprise  should  specify  its  own  conceptual  modeling  process  and  conceptual  model  products, 
using  this  guidance  as  a  point  of  reference. 

•  VV&A  of  conceptual  models  should  be  integral  to  the  development  process.  Use  of  the  ISO/IEC  9126 
standard  on  software  quality  is  a  starting  point  for  the  derivation  of  conceptual  model  quality  criteria, 
and  use  of  the  (draft)  GM-V&V  standard  is  directly  applicable  to  V&V  of  conceptual  models. 

•  Every  customization  of  the  guidance  should  be  published  to  contribute  to  the  body  of  knowledge  of 
conceptual  modeling,  to  build  a  valuable  experience  base  for  standardization  initiatives.  Especially 
important  is  the  documentation  of  decisions  on  the  mapping  of  formalisms/views/model-kinds/ 
primitives,  and  identification  of  formalisms  that  are  well  suited  to  particular  applications  or  domains. 
It  would  also  be  useful  to  develop  the  body  of  knowledge  to  determine  the  common  design  patterns 
and  appropriate  conceptual  model  component  combinations  typically  used  by  the  M&S  community. 
Improving  the  conceptual  modeling  body  of  knowledge  also  involves  the  development  of  metrics  to 
evaluate  fitness  for  purpose  of  a  conceptual  model  design. 

•  The  M&S  community  and  the  Simulation  Interoperability  Standards  Organization  (SISO)  in  particular, 
should  use  this  best-practice  guidance  as  a  basis  to  initiate  an  international  standard  for  conceptual 
model  development. 

•  As  this  guidance  was  limited  in  focus  to  conceptual  model  development,  further  work  should  be 
initiated  to  develop  best-practice  guidance  for  the  entire  conceptual  modeling  life  cycle,  including 
design  for  reuse,  collection  of  conceptual  models  for  repositories,  configuration  management, 
verification  and  validation  of  conceptual  models,  and  advancing  state-of-the-art  in  development  of 
automated  tools. 
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I.  BACKGROUND  AND  JUSTIFICATION 

Current  M&S  standards  have  provided  a  first  step  to  interoperability  and  a  state-of-the-art  way  to  interconnect 
simulations  and  tools  to  build  distributed  systems  of  simulation  but  it  is  recognized  that  existing  standards  are 
not  meant  for  exchange  of  semantics  and  concepts.  The  final  objective  of  the  TG  is  to  achieve  a  common 
understanding  and  use  of  information  exchanged  between  simulations  for  better  satisfying  military 
requirements  for  education,  training  and  operational  support.  Conceptual  models  are  key  to  the  transformation 
of  user  needs  and  requirements  to  M&S  design,  and  eventually  implementation.  The  purpose  of  this  NMSG 
TG  is  to  develop  a  guidance  document  on  Conceptual  Models,  which  can  be  used  in  the  future  by  NATO  to 
support  M&S  requirements. 


II.  OBJECTIVE(S) 

Major  objectives  of  this  Task  Group  are  to: 

•  Clarify  the  “Conceptual  Model”  concepts,  discuss  the  terminology,  and  emphasize  the  utility  to  better 
formalize  Conceptual  Models,  etc.; 

•  Investigate  methodologies,  simulation  and  software  engineering  processes,  initiatives  and  technologies; 

•  Draft  a  guidance  document  on  conceptual  modelling  that  can  be  used  by  different  stakeholders;  and 

•  Foster  the  establishment  of  the  guidance  document  as  a  SISO  standard. 


III.  TOPIC  TO  BE  COVERED 

The  first  step  will  be  to  clarify  what  a  conceptual  model  for  Military  M&S  is  and  what  it  represents. 
A  common  understanding  is  that  conceptual  models  should  serve  as  frames  of  reference  for  simulation 
development  by  documenting  important  entities/concepts,  their  properties,  and  their  key  actions  and 
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interactions:  a  conceptual  model  should  bridge  between  the  requirements  and  simulation  design.  The  second 
step  will  consist  to  investigate  methodologies,  simulation  and  software  engineering  processes,  initiatives  and 
technologies  useful  for  the  establishment  and  content  of  conceptual  models.  The  final  work  will  be  to  provide 
a  tailorable  set  of  guidance  to  the  M&S  community  on  conceptual  modeling.  This  will  guide  users  through  the 
conceptual  modeling  effort  by  explaining  how  to  apply  it  in  practice.  If  possible  a  future  guidance  will  be 
proposed  to  the  international  community  for  standardization  via  the  SISO  (Simulation  Interoperability 
Standards  Organization). 

Deliverables  and/or  end  product: 

The  final  report  should  be  a  “guidance  document”  freely  available  to  the  international  community. 


IV.  DELIVERABLE 

Technical  Report. 


V.  TECHNICAL  TEAM  LEADER  AND  LEAD  NATION 

Co-Chair:  Mr.  William  F.  Waite,  United  States. 

Lead  Nation:  United  States. 


VI.  NATIONS  WILLING/INVITED  TO  PARTICIPATE 

Canada,  France,  Netherlands,  Norway,  Romania,  Spain,  Sweden,  Turkey,  United  Kingdom,  United  States. 


VII.  NATIONAL  AND/OR  NATO  RESOURCES  NEEDED 

Nations  should  provide  funding  for  their  own  participation  (manpower  and  traveling  resources). 


VIII.  RTA  RESOURCES  NEEDED 

RTA  will  publish  the  final  report  and  electronic  support  through  its  RTO  Wise. 


IX.  ADDITIONAL  INFORMATION 

Limited  Participation  Technical  Team:  No. 

Comments:  This  activity  will  be  co-chaired  by  the  USA  and  Romania. 
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RTG  on 

Conceptual  Modelling  for  M&S 
MSG-058,  RTG-038 


I.  ORIGIN 

A.  Background 

The  NMSG  was  established  within  the  Research  and  Technology  Organisation  (RTO)  in  1999,  with  an 
objective  to  favour  re-use  and  interoperability  of  M&S  within  the  Alliance,  and  NATO/PfP  Nations.  So  far, 
within  NATO,  like  in  the  international  M&S  community,  the  interoperability  objective  was  mainly  addressed 
at  the  “technical  level”  using  open  standards  developed  by  SISO  (Simulation  Interoperability  Standards 
Organization),  IEEE  (Institute  of  Electrical  and  Electronics  Engineers)  or  ISO  (International  Organisation  for 
Standardisation)  such  as  the  HLA  that  was  adopted  by  NATO  as  early  as  1998.  Those  standards  have 
provided  a  first  step  to  interoperability  and  a  state-of-the-art  way  to  interconnect  simulations  and  tools  to  build 
distributed  systems  of  simulation  but  it  is  recognized  that  existing  standards  are  not  meant  for  exchange  of 
semantics  and  concepts. 

Since  the  beginning  of  the  NMSG  activity  it  was  recognized  that  HLA  was  only  a  preliminary  step  to  satisfy 
the  M&S  technical  interoperability  concern  and  that  the  final  objective  was  still  to  achieve  a  more  ambitious 
M&S  “interoperability  level”.  This  final  objective  should  be  to  achieve  a  common  understanding  and  use  of 
information  exchanged  between  simulations  for  better  satisfying  military  requirements  for  education,  training 
and  operational  support. 

In  the  mean  time  SISO  recognized  the  importance  of  better  defining  and  advising  the  M&S  community  on  the 
importance  of  Conceptual  Models  not  only  for  the  interoperability  issue  but  also  to  form  a  basis  for  simulation 
development,  foster  re-use,  and  to  support  V&V  activities.  A  SISO  Task  Group  was  created  in  2003  to 
address  the  topic  of  Conceptual  Models  with  the  potential  objective  of  developing  a  new  standard,  or  more 
precisely  a  “guide”,  to  help  practitioners  building  Conceptual  Models.  For  various  reasons  this  SISO  Task 
Group  did  not  fully  achieve  its  goals.  Nevertheless  it  produced  some  interesting  and  valuable  output  that  can 
be  exploited  to  produce  a  recommended  practice  guide  for  the  elaboration  of  Conceptual  Models. 

The  purpose  of  this  NMSG  Task  Group  is  to  develop  a  guidance  document  on  Conceptual  Models,  which  can 
be  used  in  the  future  by  NATO  to  support  its  M&S  requirements. 

B.  Military  Benefit 

Conceptual  models  are  key  to  the  transformation  of  user  needs  and  requirements  to  M&S  design, 
and  eventually  implementation.  Conceptual  models  form  the  bridge  of  understanding  between  the  users  of 
M&S,  the  military  domain  experts  that  have  the  necessary  knowledge  that  must  be  represented  in  M&S, 
and  the  software  and  simulation  engineers  that  implement  simulations.  Without  Conceptual  Models,  history 
has  shown  that  simulation  developers  often  do  not  sufficiently  understand  the  military  domain  to  be  modelled 
and  implement  M&S  that  do  not  reflect  the  intended  reality,  and  thus  do  not  satisfy  the  user’s  needs.  Further, 
Conceptual  Models  form  the  basis  of  an  important  step  in  Verification  and  Validation  -  determining  that  the 
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application  domain  has  been  described  sufficiently  to  meet  users’  needs  while  accurately  incorporating  subject- 
matter  expert  knowledge. 

In  addition  to  playing  a  key  role  in  the  development  of  individual  simulations,  Conceptual  Models  are  also  a 
key  to  facilitating  the  valid  and  effective  composition  of  M&S  into  federations.  While  technical 
interoperability  of  simulations  has  been  thoroughly  researched  and  solutions  have  been  implemented 
(for  example,  the  High  Level  Architecture  for  M&S),  these  do  not  address  higher  levels  of  interoperability 
(semantic,  pragmatic,  and  conceptual). 

Neither  a  standard  practice  for  Conceptual  Model  development  nor  consensus  definition  of  Conceptual  Model 
content  currently  exists.  Where  conceptual  modelling  is  practiced,  it  is  typically  defined  on  a  project-to- 
project  basis.  A  NATO  Task  Group  (TG),  working  in  conjunction  with  SISO,  is  in  the  unique  position  to 
develop  a  standard  that  will  be  used  by  multiple  Nations,  thus  meeting  the  reusability  and  interoperability 
goals.  A  recommended  practice  including  specification  of  the  content  of  Conceptual  Models  for  M&S  will 
further  increase  user  understanding  of  the  capabilities  of  those  M&S,  thus  increasing  their  reusability. 


II.  OBJECTIVE 

Major  objectives  of  this  Task  Group  are: 

•  Clarify  the  “Conceptual  Model”  concepts,  discuss  the  terminology,  and  emphasize  the  utility  to  better 
formalize  Conceptual  Models,  understand  the  relationship  between  conceptual  modelling  and  related 
concepts  (scenario  definition,  etc.); 

•  Investigate  methodologies,  simulation  and  software  engineering  processes,  initiatives  and 
technologies  useful  for  the  establishment  and  content  of  Conceptual  Models; 

•  Draft  a  guidance  document  on  conceptual  modelling  that  can  be  used  by  different  stakeholders 
(sponsor/user,  project  manager,  subject-matter  experts,  V&V  agents,  developers,  etc.);  and 

•  Foster  the  establishment  of  the  guidance  document  as  a  SISO  standard. 

The  TG’s  first  objective  will  be  to  clarify  what  a  Conceptual  Model  for  Military  M&S  is  and  what  it 
represents.  A  common  understanding  at  this  starting  moment  is  that  the  Conceptual  Model  should  serve  as  a 
frame  of  reference  for  simulation  development  by  documenting  important  entities/concepts,  their  properties, 
and  their  key  actions  and  interactions.  That  is  a  Conceptual  Model  should  bridge  between  the  requirements 
and  simulation  design. 

The  TG  will  clarify  and  rigorously  define  the  core  terminology  associated  with  conceptual  models  and 
conceptual  modelling,  and  the  relationship  among  those  terms.  The  TG  will  identify  the  key  stakeholders  in 
conceptual  modelling  and  their  requirements  with  respect  to  conceptual  modelling.  Stakeholders  will  include 
those  that  are  involved  in  the  production  of  conceptual  models  and  those  that  rely  on  conceptual  models  to 
perform  their  jobs.  Among  the  issues  the  TG  will  address  what  key  concepts  each  of  these  stakeholders  needs 
in  a  conceptual  model  and  the  level  of  abstraction  at  which  conceptual  models  should  be  expressed  to  meet 
various  stakeholders’  needs. 

Conceptual  modelling  is  one  of  key  concepts  in  the  development  and  employment  lifecycle  of  M&S.  As  such 
it  is  related  to  other  concepts  such  as  scenario  development,  simulation  software  requirements  development, 
and  test  plan  development.  As  part  of  the  first  objective,  the  TG  will  define  the  relationships  among 
conceptual  modelling  and  these  other  activities.  The  second  objective  of  this  Task  Group  is  to  investigate 
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methodologies,  simulation  and  software  engineering  processes,  initiatives  and  technologies  useful  for  the 
establishment  and  content  of  Conceptual  Models.  While  the  objective  of  this  TG  is  not  to  develop  or  identify  a 
single  standard  for  the  representation  of  conceptual  model  content,  this  TG  will  identify  a  range  of  such 
solutions  that  can  be  employed  in  conceptual  modelling. 

In  order  to  take  advantage  of  the  work  covered  by  others  regarding  to  this  issue,  it  will  be  very  important  to 
collect  and  analyze  as  much  as  possible  of  the  documentation  available  on  conceptual  modelling,  specially 
those  related  to  the  M&S  field.  Lesson  learnt  by  them  can  help  to  avoid  some  recurrent  problems,  to  reduce 
the  risk  of  developing  simulation  not  adapted  to  the  requirements  and  to  get  a  better  profit  of  this  TG. 

The  TG  will  explore  the  potential  of  a  variety  of  processes  and  knowledge  representation  approaches  to 
examine  their  potential  for  conceptual  modelling.  Among  these  will  be  simulation-specific  methodologies  as 
the  HLA  FEDEP  general  software  engineering  processes;  prior  conceptual  modelling  initiatives  as  the  CMMS 
-  Conceptual  Models  of  the  Mission  Space,  and  emerging  technologies  such  as  ontology  languages.  Through 
this  objective,  the  TG  will  synthesize  existing  practices  to  identify  the  state  of  the  art  of  conceptual  modelling. 
By  doing  this,  the  TG  will  maximize  the  reuse  of  previous  effort  in  the  development  of  a  recommended 
practice. 

The  third  objective  is  to  provide  a  tailorable  set  of  guidance  to  the  M&S  community  on  conceptual  modelling. 
This  will  guide  users  through  the  conceptual  modelling  effort  by  explaining  how  to  apply  it  in  practice. 
The  process  will  be  tailorable  in  that  it  is  intended  to  be  extended  and  modified  by  individual  programs  that 
apply  it.  Rather  than  being  a  one-size-flts-all  rigid,  single  approach  to  conceptual  modelling,  the  guidance  will 
provide  a  starting  point  that  individual  programs  can  apply  given  their  specific  needs  and  resources. 
The  guidance  on  the  Conceptual  Model  content  will  state  what  should  be  in  the  Conceptual  Model,  and  not 
mandate  a  specific  format  but  suggestions  for  the  selection  and  use  of  format,  methodology,  techniques  and 
tools  will  be  provided. 

The  guidance  will  encompass  the  conceptual  modelling  process,  Conceptual  Model  content  and  describe 
appropriate  views  on  a  Conceptual  Model  for  different  stakeholders.  For  example,  the  conceptual  modelling 
process  will  describe  the  transformation  from  the  users  view,  concerned  with  the  problem  domain,  to  the 
developers  view,  focused  on  the  M&S  domain. 

The  TG’s  fourth  objective  is  to  foster  the  establishment  of  the  guidance  document  as  a  SISO  standard. 
The  current  policy  of  NATO  for  standardization  is  to  use  civil  standards  where  appropriate  ones  exist  and  to 
develop  its  own  standards  only  when  no  civil  standard  exists.  In  the  case  of  conceptual  modelling  for  M&S  or 
conceptual  modelling  in  general,  no  civil  standard  exists.  The  requirement  for  M&S  Conceptual  Modelling  is  not 
specific  to  NATO  or  to  the  military  domain.  Thus  it  should  be  helpful  to  extend  this  work  to  a  larger  M&S 
community.  With  respect  to  this  proposal,  the  TG  will  open  its  guidance  document  to  an  M&S  standard  product, 
developed  through  an  open  consensus-based  standards  body.  The  SISO  is  the  best  suited  organization  for  this 
standardization,  since  it  has  a  strong  background  and  current  focus  on  military  M&S,  but  also  includes  M&S 
practitioners  from  outside  the  military  domain.  Thus,  the  TG  will  propose  to  SISO  the  creation  of  a  standard 
development  group  (a  PDG,  Product  Development  Group)  in  charge  of  developing  a  balloted  standard. 

Two  models  of  interaction  between  this  NMSG  TG  and  the  SISO  PDG  are  possible: 

1)  The  TG  guidance  document  can  provide  the  first  draft  of  the  future  SISO  product  which  can  benefit 
from  the  input  of  a  larger  M&S  community;  or 

2)  The  TG  will  work  along  with  a  SISO  PDG  to  develop  the  product. 
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The  decision  rests  with  the  SISO  membership  and  the  SISO  Standards  Activity  Committee  on  whether  they 
wish  to  apply  the  resources  immediately  to  exercise  the  second  option.  In  either  case,  the  TG  will  be  involved 
in  the  SISO  PDG  activity  and  could  provide  a  part  of  the  leadership  of  the  group  thus  protecting  its  own 
interests.  This  working  mode  between  NATO  Task  Groups  and  SISO  Product  Development  Groups  has 
already  been  employed  in  the  VV&A  (Verification,  Validation  and  Accreditation)  and  Coalition  Battle 
Management  Language  (C-BML)  activities.  Even  if  the  first  cooperative  approach  is  used,  and  SISO  does  not 
choose  to  take  the  product  forward  as  a  SISO  product,  NATO  will  be  provided  with  a  guidance  document  as 
proposed  in  the  third  objective  at  the  end  of  the  TG  activity. 

Main  deliverables  of  the  Task  Group  will  be: 

•  A  draft  guidance  document; 

•  Interim  publications  at  some  conferences  (when  required);  and 

•  A  final  report. 

III.  RESOURCES 

A.  Membership 

Co-Chair:  Mr.  William  F.  Waite,  United  States. 

B.  Nations  Willing/Invited  to  Participate 

Canada,  France,  Netherlands,  Norway,  Romania,  Spain,  Sweden,  Turkey,  United  Kingdom,  United  States. 

Task  Group  members  must  have  a  working  knowledge  of  the  simulation  design  and  development.  An  initial  list 
of  Nations,  which  have  expressed  a  willingness  to  participate,  is  given  above. 

Other  Nations  can  express  willingness  to  participate  in  this  activity.  It  is  recommended  that  USA  and  Romania 
co-chair  this  activity. 

National  and/or  NATO  resources  needed: 

•  Member  Nations  will  supply  manpower  (including  travelling  expenses)  resources.  It  is  important  that 
the  group  be  supported  by  the  NATO  Modelling  and  Simulation  Coordination  Office  (MSCO). 

RTA  resources  needed: 

•  Technical  report  publication  services. 

•  RTO  Web  Space  via  the  RTO  Wise. 

IV.  SECURITY  LEVEL 

The  security  level  will  be  Unclassified/Unlimited. 


V.  PARTICIPATION  BY  PARTNER  NATIONS  AND  OTHER  NATIONS 

This  activity  is  open  to  PfP. 
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VI.  LIAISON 

Liaison  should  be  established  with  the  following  organisations: 

•  MSG-054  Task  Group  on  “An  Overlay  Standard  for  Verification,  Validation,  and  Accreditation 
(VV&A)  of  Federations”; 

•  MSG-052  Task  Group  on  “Establishment  of  a  Knowledge  Network  for  Federation  Architecture  and 
Design”; 

•  The  coming  Task  Group  IST-075/RTG-034  on  “Semantic  Interoperability”  (Continuation  of  the  1ST 
group  ET-040  on  “Ontology  fusion”); 

•  Simulation  Interoperability  Standards  Organisation  (SISO);  and 

•  Other  RTO  Task  Groups  as  required. 

VII.  REFERENCE 

The  deliverables  should  be  “Unclassified  -  Approved  for  Public  Release  (unlimited  distribution)”. 
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Annex  C  -  TAP/TOR  REQUIREMENTS 


REQUIREMENT 

COMPLIANT 

Comply  with  TAP-TOR  guidance  language  ...  as  interpreted 

X 

Sufficiently  serve  all  relevant  stakeholders 

X 

Be  demonstrably  and  fully  relevant  to  (but  not  strictly  limited  to)  best-practice. . . 

X 

Modeling  and  simulation  life-cycle 

X 

Defence  industry  enterprise 

X 

Facilitate  broad-based  M&S  standards  evolution 

X 

Conceptual  Model  has  to  be  something  useful  to  the  M&S  community  to  understand  clearly 
those  aspects  of  the  reality  that  must  be  implemented  in  a  simulator 

X 

Conceptual  model  has  to  be  enough  open  to  get  that  it  will  be  reusable  by  anyone  that  face 
similar  problems  in  the  same  domain  of  knowledge 

X 

The  guidelines  have  to  become  in  a  standard  for  conceptual  model  in  M&S 

X 

Guidance  to  address  the  conceptual  model  needs  of  NATO  military  M&S  (4)  Stakeholders, 
while  keeping  in  mind  that  the  related  processes  and  technology  solutions  may  be  applicable 
to  a  larger  audience  (non-military,  non  M&S).  We  must  be  enough  specific  (military  / 

M&S)  to  produce  a  useful  and  applied  guidance  document  but  nothing  more  specific  than 
that.  If  the  specification  does  not  bring  clarity,  useful  /  applicability  of  the  guidance,  we 
must  admit  it. 

X 

Priorities  in  topic  discussion  be  addressed 

X 

[Address  needs  of  4]  stakeholders 

X 

Final  product  should  be  as. . .  general  as  possible 

X 

Relevant  to  military  M&S  but  not  proscribe  practices  that  would  preclude  uses  within  other 
areas  (as  for  instance,  Enterprise  modeling) 

X 

Consider  adoption/tailoring  of  the  4-actor  view  of  stakeholders 

X 

Primary  emphasis  on  the  needs  of  the  [simulation]  developer 

X 

Ensure  stakeholders,  use  cases,  definitions  and  applications  are  applicable  to  the  military 
and  M&S  areas 

X 

If  we  discover  during  the  process  that  we  must  give  specific  guidance  that  limits  the  scope 
to  military  or  M&S,  we  will  constrain  ourselves  only  to  the  minimum  degree  necessary  to 
address  the  specific  case 

X 

Other  than  military  and  M&S  areas  we  have  no  other  scope  constraints 

X 

Convey  M&S  as  prime  concern  versus  information  systems  in  general 

X 

Cover  military  as  primary  concern  versus  other  domains 

X 
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REQUIREMENT 

COMPLIANT 

Identify  specific  stakeholders  in  the  [military  and  M&S  ]  domains  to  capture  their 
requirements  on  conceptual  models  but  try  not  to  limit  the  conceptual  model  for  only  those 
domains 

X 

Scope  driven  from  stakeholder’s  needs 

X 

Focus  on  defence  establishment 

X 

Focus  on  M&S  development 

X 

Stakeholder  roles  to  be  advanced  somewhere  between  4  of  NMSG  -042  and  Colonel  Smith 

X 

Use  of  generally  accepted  practice  in  the  computer  science  establishment 

X 

[address]  Definition  of  conceptual  model 

X 

[address]  How  conceptual  model  can  address  military  simulation  shortcomings 

X 

[include]  General  evaluation  of  conceptual  model  use  cases  versus  actual  technology  use 
cases 

X 

[provide]  Guidance  to  implementation  of  conceptual  models 

X 

[provide]  Guidance  to  possible  standards 

X 

Conceptual  model  [practice  and  artefact]  has  to  be  something  useful  to  the  M&S  community 
to  understand  clearly  those  aspects  of  the  reality  that  must  be  implemented  in  a  simulation 

X 

Conceptual  model  [practice  and  artefact]  has  to  be  open  enough  that  it  will  be  accessible  by 
anyone  who  face[s]  similar  problems  in  the  same  domain  of  knowledge 

X 

Guidance  [has]  to  become  a  standard  for  conceptual  modeling  in  M&S 

X 
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Annex  D- ISSUES 


In  order  to  identify  and  subsequently  resolve  issues  (i.e.,  topics  whose  deep  appreciation  and  consensus  resolution 
by  the  Group  members  would  likely  be  necessary  to  the  successful  completing  of  the  MSG-058  effort)  the  Task 
Group  resolved  to  systematically  review  the  prospective  study  and  establish,  by  consensus,  topic  areas 
considered  deserving  attention.  The  first  step  in  this  process  was  to  discuss  potential  difficulties  in  areas  of: 

•  General  and  Administrative  conduct  of  the  effort; 

•  Elements  of  the  Programme  of  Work;  and 

•  Matters  of  Technology  that  were  likely  to  challenge  the  Group  in  successfully  completing  its  assignment, 
and  considerations  related  to  the  intended  Work-Product. 

In  doing  so,  as  completely  and  systematically  as  possible,  our  intention  was  as  follows: 

•  Ensure  that  each  national  participant  nominated  at  least  one  issue  topic  of  particular  concern; 

•  Ensure  that  at  least  one  topic  was  nominated  for  consideration  by  each  individual  participating  in  the 
study; 

•  Arrange  that  each  topic  was  ‘adopted’  by  some  one  individual,  who  would  be  depended  upon  to  pursue 
resolution  throughout  the  study  process;  and 

•  Arrange  that  each  adoption  allowed  individuals  with  special  intensity  of  concern  for  a  topic  to  influence 
the  Group’s  treatment  of  that  topic  issue  to  their  particular  satisfaction. 

This  intention  for  issue  management  activity  is  indicated  in  the  following  figure,  where  abbreviated  topic  titles 
associated  with  General  and  Administrative,  Programme  of  Work,  Technology  and  Work-Product  specification, 
generation,  and  publication  respectively. 
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Issue  -  Action  Intention 

•  >  0  Topic/Nation 

•  >  0  Topic  by  all 

•  Each  topic  adopted  by  someone 

•  ‘Adopt*  your  favorite  topics 


General  &  Administrative 

Issue 

Action 

•Collaboration 

BW-  Telecons  between  mtgs 
All  -  use collab  environment 

•  Other  data/arch/ 

BW-task  SIW 

SIW/sim  summit 

•MSG  04 2/1 ST  075 

SP-  mtg  attention  (Madrid) 

All  -  report  ad  hoc 

JL 

Proqram  of  Work 

Issue 

Action 

•  TPP 

BW-  draft  by  30  Aug 

•  sched  duration 

BW-  MS  proj  schedule 

•  RPT  NATO  BW 

BW 

Technoloqv 

Issue 

Action 

-  Lexicon,  def ,  scope 

SE  -  Def  CM/Gloss  scope 

MS  vs  SE,  Mil  vs  other, 

Exec  v&  Rep 

-  Ontology/ KAKI /IT 

SP  -  Tutorial' 

field  of  regard 

-  Rel  to  W&A,  DoDAF,  C4I 

NL  -  Rel  diagrams 

Stds,  HLA  Fedep 

•  Function  vs  Object 

- 

■  Specification  of  CM  product/process 

CA-  explication/recommend 

•  Interface  as  content 

- 

•  Patterns/meta-mo  del/stereotype 

CA-  explication/recommend 

-  Subjective  bias  influence/effects. 

- 

mitigation 

XL 


Work  Product 

Issue 

Action 

•  Needs->Rqmts 

All 

■  Product  structure/arch 

NO  -  draft  by  30  Aug 

■Stakeholder  analysis 

All  -  enterprise  map 

•  Emphasis:  man  vs  machine 

SE  -  frame/recommend 

•  Guidance  rigor  (formality) 

- 

(computational  vs  expressive) 

•  Initiate  practice 

US  -  coord  use  cases 

(launch/promulgate/use) 

•  Rel  to  BOM,  CBML,  CML,  othet 

- 

*  Spec 

- 

•  Features 

Figure  D-1:  Outline  of  Scope  and  Influence  Among  Topic  Issues  Identified  by  the 
Task  Group  in  Anticipation  of  Initiation  of  Detailed  Programme  of  Work. 


It  was  further  resolved  by  the  Task  Group  that  for  each  issue  topic,  the  designated  agent,  would  provide  a 
definition,  indicate  stakeholder  needs,  specify  the  scope  of  concern  of  the  topic,  and  establish  other  such  attributes 
of  the  identification  and  specification  of  the  issue,  together  with  recommendations  of  actions  whereby  the 
effect  of  each  issue  in  areas  of  Technology,  Work-Product,  Programme  of  Work,  and  meta-process  would  be 
made  a  matter  of  record  and  so  duly  respected  by  the  team  during  the  consequent  effort.  This  intention  is 
indicated  diagrammatically  in  the  following  figure. 
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Candidate  Issue  Topics 

♦Definition 

•  Stakeholder  Diverse  Needs 
•Scope  (Sim  Exec  vs  Sim  Rep) 

(M&Svs  SE) 

(Mil  mission  space  vs 

other) 

•  Relation  to  VVA(rqmts,  products) 

•  Guidance  Rigor 

•  Ontological  practice  options 

•  Launch  promulgateuse 


> 


I 


Tcchnolouv 

Product 

Proorsm 

Meta-Process 

Issues 

Actions 

Name 

Name 

Specification 

Need 

Risk-Opportunity 

Activity 

Implications 

Require 

Resolve 

Result/Product 

Strategic/Tactical  Approach 

m 

- ff 

ResponsibleAgent 

Date  Identified 

Assigned  Date 

Date  Resolved 

Due  Date 

Status 

Affect 

Status 

ResponsibleAgent 

gcUabcraflYS  Wgfhgpgcs 

'  Tebles  (Issues,  actions, ... 

•  RDBMS? 

•  ProductSpsc 

•  Program  Spec  (Pro)) 

•  Debate 

•  Refs 

• 


Figure  D-2:  Schematic  of  Specification  of  Topical  Issue,  Resolution  Action  and  Influence. 


Finally,  the  suite  of  issues  so  identified  were  reviewed  by  the  Team  in  order  to  establish  a  priority  list  and  to 
identify  the  highest  priority  issue  topics  in  order  that  the  sensitivity  of  the  study  Task  Group  might  continue  to 
be  focused  on  a  consensus  basis  throughout  the  duration  of  the  effort.  The  list  that  follows  indicates  the  5  most 
important  topical  issues  identified  by  consensus  of  the  group. 

1)  Stakeholder  Analysis  and  Context; 

2)  Scope  and  definition; 

3)  Relationship  to  standards; 

4)  Specification  of  Conceptual  Model  Management  Process;  and 

5)  Specification  of  Conceptual  Model  Artefact. 

The  following  table  provides  the  details  of  the  priority  vote-ordering  of  the  total  list  of  topical  issues  considered. 
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Table  D-1 :  Total  List  of  Candidate  Topic  Issues,  With  Team  Vote  Compilation  of  Significance  of  Each. 


Circumstances  and  Analytical  Context: 

Score  1-5 

Stakeholder  Analysis  and  Context  (20) 

1,1,1,2,1,1,1,1,2^11 

Effort  Analytical  Frame  (e.g.  'Conceptual  model’  versus  'Ontology’  ...  DODAF, 

MDA  versus  ontology  . . .system  eng,  software  eng,  ?  engineering. . .  OWE  /  Rules  . . . 
'ontology’  pragmatic  selection  of  operating  locus  within  the  manifold  of  knowledge 
management  ->  capture  as  'operational  strategy’) 

2, 3, 2, 3, 3, 2,2, 2, l,->20 

Intention: 

Product  influence-utility  scope  . . .  “Scope”  -  M&S?  Military?  Versus  SE?  Executable 
versus  Representation?  Order  (CM  /  Mil  /  M&S  vs.  CM  /  M&S  /  Mil) 

1,2, 1,1, 1,2, 1,1, 1,->11 

Guidance  rigor  (22) 

3, 1,3, 3, 2, 1,2, 2, 3, ->20 

Style  of  influence  (e.g.  CMMI?) 

Authoritative  standing 

Enforcement  strategy 

Product  Development  and  Deployment: 

Product  needs/requirements  discrimination  (18) 

4, 3, 3, 4, 1,2, 3, 4, 3, ->27 

Work-  Product  content  structure/architecture  (19) 

1 ,5,3,3, 1,3,1, 2, 4->23 

Exposition 

Lexical  analysis  and  documentation  (10) 

Reference  analysis  and  documentation 

Specification  of  Conceptual  Model  Management  Process 

1,1, 1,1, 2, 2, 1,1, 2,- ->12 

Process  content 

Expository  schema 

Subjective  bias/influence/effects  (ontological  relativism)  mitigation  (17) 

Specification  of  Conceptual  Model  Artefact  (14) 

1,1, 1,1, 1,1, 1,1, 2,- ->10 

Specification  requirements 

Expository  Schema 

Conceptual  Model  contingency  with  respect  to  detail  of  conceptual  model,  its 
relationship  to  simulation  lifecycle  evolution,  it  multiplicity  of  views,  its 
computability  and  its  creditability. 

Prototyping  with  Guidance-Product 

3, 4, 3, 1,3, 4, 4, 3, 3, ->28 
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Circumstances  and  Analytical  Context: 

Score  1-5 

Product  Development  and  Deployment  (cont’d): 

Identify/enlist  trial-horse  sample  problems 

Establish  preliminary  guidance 

Execute  prototype 

Abstract  lessons  learned 

Document  effort 

Deployment/employment  of  guidance 

5,3,3, 1,4, 2, 2, 3, 4, -»27 

Recommendations 

Initiate  practice  (23) 

Deployment  Campaign 

Institutional  Coordination 

Technical  Considerations: 

Ontology  (11) 

2, 2, 1,1, 4,1, 1,2, 3,' *17 

Function  versus  Object  (13) 

4, 4, 2, 5, 1,2, 4,5, 2,- *29 

Emphasis  man  vs.  machine  (21) 

5, 2, 1,2, 4, 1,2, 4, 2, -»23 

Interface  (only)  vs.  Context  (15) 

2,3, 2, 5,3,3, 4, 3, 1,^26 

Patterns/meta-model/stereotype  (16) 

2,3,2,5,4,3,2,2,4^27 

Relationship  to  Standards  ...  DODAF,  etc.  others 

2, 1,2, 1,3, 1,1, 1,1, *13 

Relationship  to  VV&A  (12) 

1,2,2,2,2,3,3,3,2,^20 

Relationship  to  BOM,  CBML,  CML,  other  (24) 

2,2,2,2,33,2,2, 1  1 9 

Intellectual  Property  management 

3,5,4,3,4,5,3,4,5^36 
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Annex  E  -  EXPLANATION  OF  FUNDAMENTAL  CONCEPTS 
FOR  CONCEPTUAL  MODEL  FRAME-OF-REFERENCE 


In  order  to  better  understand  and  incorporate  into  the  best-practice  guidance  specified  in  detail  in  following 
annexes,  the  Task  Group  undertook  an  analysis  of  fundamental  concepts  for  conceptual  model  composition  and 
specification.  This  analysis  addressed  particularly  the  differences  and  similarities  between  a  variety  of  commonly 
used  conceptual  models,  formalisms  and  ontologies.  This  analysis  had  as  its  objective  the  following: 

•  Give  appropriate  and  necessary  definitions.  Discuss  the  differences  and  the  benefits  of  natural  languages , 
artificial  languages,  and  machine  languages. 

•  Discuss  the  possibility  to  verify  the  models  by  rules  and  constraints  -  if  they  have  formal  representations. 

•  Explain  how  to  transform  an  informal  conceptual  model  into  a  formal  or  semi-formal  model. 

•  Discuss  Machine  Readability  -  e.g.,  to  make  an  ontology  ‘machine-readable’  we  need  to  select  a  formal, 
machine-processable  implementation  language. 

•  Show  the  steps  towards  making  the  human-readable  information  also  machine-readable.  (One  of  the 
accepted  ways  of  expressing  such  machine  readable  conceptual  models  is  UML  (Unified  Modeling 
Language).  UML  is  being  used  for  far  more  than  simply  conceptual  modeling.  Additionally,  UML  class 
diagrams  (conceptual  models)  can  be  categorized  as  semi-formal  ontologies  themselves.  (Semi-formal 
because  they  are  not  directly  machine-readable.)  However,  tools  are  being  developed  that  enable 
automatic  transformation  from  UML  class  diagrams  to  ontology  formalisms  like  DARPA  Agent  Markup 
Language  (DAML),  OWL,  etc.). 

E.l  OVERVIEW 

To  determine  what  can  be  a  good  conceptual  frame  for  a  set  of  elements  for  capturing  the  semantic  contents 
necessary  and  sufficient  for  a  conceptual  model,  we  have  reviewed  a  number  of  methods  known  to  the  Task 
Group  to  be  relevant  and  representative  for  use  for  conceptual  modeling.  We  identified  and  studied  sixteen 
(16)  different  methods/templates  and  have  noted  their  properties,  their  most  important  information  elements, 
parameters,  etc.  The  results  of  this  analysis  revealed,  as  expected,  the  common  factors  among  them  from 
which  we  could  select  attributes  of  the  consequent  conceptual  model  specification  prescriptive  guidance  to 
follow. 

Given  this  analysis,  a  synthesis  step  followed.  Having  found  the  denotative  name  for  information  elements,  their 
information  content,  and  justification  of  their  necessity;  we  allocated  those  elements  to  our  nascent  conceptual 
modeling  process  and  product.  Taken  together  with  the  options  are  their  representation/specification,  and  the 
degree  their  quality  should  be  certified;  we  proceeded  to  successfully  generate  a  table  of  semantic  contents 
necessary  and  sufficient  for  a  conceptual  model,  along  with  their  qualifying  attributes  and  other  necessary 
information. 

Lor  the  purpose  of  this  analysis/synthesis,  the  following  terminology  is  relevant: 

•  A  ‘Behavior’  is  the  means  an  Actor  uses  to  actuate  Events. 

•  An  ‘Actor’  is  the  subject  of  action. 

•  An  ‘Event’  is  an  action  composed  of  Activities. 
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•  A  ‘Control’  defines  what  can  occur  within  an  Activity. 

•  ‘Information’  details  the  capabilities  of  a  Behavior,  Actor,  Event,  or  Control. 

Using  this  vernacular,  a  process  is  specified  (in  the  present  context),  thus: 

Using  <Behaviors>,  an  <Actor>  actuates  <Events>  composed  of  <Activities>  that  are  directed  by 
<Controls>  and  richly  described  by  <Information>. 

. . .  where  the  text  indicated  within  carets  as  reserved  words  are  used  below  in  tabulating  the  model  schema 
characteristics  in  tabular  form  for  each  model  schema  analyzed. 


E.2  ANALYSIS 

Analysis  of  conceptual  schema  alternative  styles  follows,  given  the  primitives  established  above.  In  each  case, 
we  identify  the  schema,  and  characterize  it  systematically  in  order  both  to: 

•  Appreciate  its  intrinsic  nature  and  the  systematic  relationships  among  alternative  typical  relevant 
schema;  and 

•  Provide  evidence  to  the  effect  that  the  use  of  the  normative  precept  above  is  sufficient  for  any 
conceptual  model  specification. 

E.2.1  Method:  BOM  [1] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Patterns  of  interplay: 

A.  Identifies  a  sequence  of  actions. 

II.  State  machines: 

A.  Identifies  the  behavior  states  expected  to  be  exhibited  by  one  or  more  conceptual  entities. 

III.  Event  type  (Conceptual  events): 

A.  Describes  the  types  of  events  that  are  the  result  of,  or  triggered  from,  actions  relevant  in  a  pattern 
of  interplay. 

B.  Two  types: 

1.  Triggers. 

2.  Messages. 

IV.  Entity  type  (Conceptual  entities): 

A.  Types  of  conceptual  entities  that  represent  senders  and  receivers  of  information  in  a  pattern  of 
interplay. 

B.  Object  classes. 

C.  Interaction  classes. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 
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Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

State  machines 

Entity  type 

Event  type 

Patterns  of 
interplay 

(Object  class) 

(Triggers) 

(Interaction 

class) 

(Messages) 

E.2.2  Method:  BOM++  [2] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Patterns  of  interplay: 

A.  Identifies  a  sequence  of  actions. 

B.  Identifies  the  behavior  states  expected  to  be  exhibited  by  one  or  more  conceptual  entities. 

II.  Event  type  (Conceptual  events): 

A.  Describes  the  types  of  events  that  are  the  result  of,  or  triggered  from,  actions  relevant  in  a  pattern 
of  interplay. 

B.  Two  types: 

1.  Triggers. 

2.  Messages. 

III.  Entity  type  (Conceptual  entities): 

A.  Types  of  conceptual  entities  that  represent  senders  and  receivers  of  information  in  a  pattern  of 
interplay. 

B.  Extended  through  use  of  Namespace  Qualified  Extensions. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

State  machines 

Entity  type 

Event  type 

Patterns  of 
interplay 

(Object  class) 

(Triggers) 

(Interaction 

class) 

(Messages) 

E.2.3  Method:  BPMN  [3] 

BPMN  is  particularly  conceived  to  meet  the  following  criteria: 

•  Designed  to  be  usable  to  business  community;  and 

•  Must  generate  executable  processes  through  a  BPMN  model,  coupled  with  some  additional  information. 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 
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I.  Activities: 

A.  Work  that  is  performed  within  a  business  process. 

B.  Can  be  atomic  or  non-atomic  (compound). 

C.  Activities  that  are  a  part  of  a  Process  Model  are: 

1.  Sub-Processes: 

a)  A  compound  activity  included  within  a  Process: 

(1)  Can  be  broken  down  into  a  finer  level  of  detail  (a  Process)  through  a  set  of  sub¬ 
activities. 

(2)  Enables  hierarchical  process  development. 

(3)  Two  types: 

(a)  Embedded. 

(b)  Independent  (reusable). 

II.  Task: 

A.  An  atomic  activity  that  is  included  within  a  Process. 

B.  Used  when  the  work  in  the  Process  is  not  broken  down  to  finer  level  of  Process  Model  detail. 

C.  Can  be  looped. 

III.  Events: 

A.  Something  that  “happens”  during  the  course  of  a  business  process. 

B.  Affect  the  flow  of  the  Process. 

C.  Usually  have  a  trigger  or  a  result. 

D.  Can  start,  interrupt,  or  end  the  flow: 

1 .  Start: 

a)  Indicates  where  a  Process  will  begin. 

2.  Intermediate: 

a)  Occur  after  a  process  has  been  started  and  before  a  process  is  ended. 

3.  End: 

a)  Indicates  where  a  process  will  end. 

IV.  Gateways: 

A.  Modeling  elements  that  are  used  to  control  how  Sequence  Flows  interact  as  they  converge  and 
diverge  within  a  Process: 

1 .  Exclusive  Gateways  (decisions): 

a)  Locations  within  a  business  process  where  the  Sequence  Flow  can  take  two  or  more 
alternative  paths. 

b)  Only  one  of  the  possible  outgoing  paths  can  be  taken  when  the  Process  is  performed: 

(1)  Two  types  decision  mechanism: 

(a)  Data. 

(b)  Events. 

(c)  A  branching  point  in  the  process  where  the  alternatives  are  based  on  events  that 
occurs  at  that  point  in  the  Process,  rather  than  conditions. 

2.  Inclusive  Gateways: 

a)  Where  there  is  more  than  one  possible  outcome. 

3 .  Complex  Gateways : 

a)  Where  there  more  advanced  definitions  of  behavior  can  be  defined. 

4.  Parallel  Gateways: 

a)  Places  in  the  Process  where  multiple  parallel  paths  are  defined. 

V.  Connectors: 

A.  Sequence  Flow: 

1 .  Used  to  show  the  order  that  activities  will  be  performed  in  a  Process. 
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2.  Source  and  target  must  be  Events,  Activities,  and  Gateways. 

B.  Conditional. 

C.  Default: 

1 .  Exits  an  Exclusive  or  Inclusive  Gateway  may  be  defined  as  being  the  default  path. 

D.  Message  Flow: 

1 .  Used  to  show  the  flow  of  messages  between  two  entities  that  are  prepared  to  send  and  receive 
them. 

E.  Association: 

1 .  Used  to  associate  data,  information  and  artefacts  with  flow  objects. 

VI.  Swim-lanes: 

A.  Used  to  partition  and  organize  activities. 

B.  Pool: 

1 .  Represents  Participants  in  an  interactive  (B2B)  Business  Process  Diagram. 

C.  Lane: 

1 .  Represents  sub-partitions  for  the  objects  within  a  Pool. 

VII.  Artefacts: 

A.  Provide  the  capability  to  show  information  beyond  the  basic  flow-chart  structure  of  the  Process: 

1.  Data  Objects: 

a)  Used  to  show  how  data  and  documents  are  used  within  a  Process. 

2.  Groups: 

a)  Used  to  highlight  certain  sections  of  a  Diagram  without  adding  additional  constraints  for 
performance,  as  a  Sub-Process  would. 

3.  Annotations: 

a)  Provide  additional  information  about  a  Process. 

b)  A  modeler  or  tool  can  extend  BPMN  by  defining  new  Artefacts. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Event 

Process 

Gateways 

-  Activity 

Connector 

-  Sub-process 

-  Sequence  flow 

(embedded) 

-  Conditional 

(reusable) 

-  Default 

-  Task 

-  Message  flow 

-  Association 

Swim-lanes 

-Pool 

-Lane 

Artefacts 

-  Data  objects 

-  Groups 

-  Annotations 
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E.2.4  Method:  CML  (OneSAF)  [4] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Elements: 

A.  Real/abstract  things  making  up  and  acting  in  the  battle-space. 

B.  Belong  to  a  Category. 

C.  Have  Characteristics. 

D.  Issue  Events. 

E.  Stimulate  Behaviors. 

F.  Behaviors  change  state  of  Elements. 

G.  Two  sub-classes  of  Elements: 

1.  Piece. 

2.  Players. 

3.  Those  things  explicitly  represented: 

a)  Tanks,  infantry,  etc. 

b)  Markers. 

4.  Things  implicitly  represented: 

a)  Tactical  positions,  Psyops,  etc. 

5.  Game-space: 

a)  Environment. 

b)  Establish  physical  battle-space  whereas  Elements  have  a  location. 

6.  Zone: 

a)  Abstract  spaces  where  inhabitants  do  not  have  a  location: 

1)  Satellites  providing  intelligence. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Behaviors 

Elements 

Events 

Game-space 

Category 

-  Piece 

Zone 

Characteristics 

-  Player 

E.2.5  Method:  CommonKADS  [5] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Communication  Model: 

A.  Needs  and  desires  with  regards  to  other  agents  (e.g.,  a  user  interface  or  interfaces  with  other 
systems). 

II.  Knowledge  Model: 

A.  Knowledge  and  reasoning  requirements. 
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B.  Specifies  data  and  knowledge  structures  for  an  application: 

1 .  Domain  knowledge . 

2.  Task/Inference  Knowledge: 

a)  The  objectives  of  an  app,  together  with  how  to  achieve  these. 

b)  T asks>Sub-tasks>Elementary  inferences . 

c)  Therefore,  a  task  is  composed  of  a  number  of  combined  inferences,  documented  in  an 
inference  diagram. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Communication 

model 

Agent 

Task 

Sub-task 

Communication 

model 

Elementary 

inferences 

Knowledge 

model 

-  Domain 

-Task/ 

inference 

E.2.6  Method:  DCMF  (KM3)  [6] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Model  element: 

A.  Primary  active  object,  as  well  as  objects  that  are  part  of  actions. 

B.  Can  be: 

1.  EntityType. 

2.  RoleinAction. 

3 .  RolelnOrganizationType. 

4.  Action  Type. 

II.  Attribute: 

A.  Describes  an  optional,  measurable  characteristic  of  a  model  element. 

III.  State: 

A.  Set  of  attributes  with  values  associated  with  a  model  element. 

B.  Specifies  conditions  under  which  an  activity  starts  and  ends. 

IV.  Rules: 

A.  Description  of  changes  to  model  elements. 

B.  Rules  are  pairs: 

1.  Activity  role. 

2.  Atomic  formula: 

a)  Statement  about  the  state  or  attributes  of  a  role. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


RTO-TR-MSG-058 


E  -  7 


ANNEX  E  -  EXPLANATION  OF  FUNDAMENTAL 

CONCEPTS  FOR  CONCEPTUAL  MODEL  FRAME-OF-REFERENCE 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Element 

Activity 

State 

Attribute 

Rules 

E.2.7  Method:  DCMF  (M2CM)  [7] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Meta  data: 

A.  Provides  information  regarding  their  potential  for  reuse  in  extending  and  creating  conceptual 
models: 

1 .  POC  (Point  Of  Contact): 

a)  Holds  information  about  an  organization  or  a  person  having  a  particular  role  with  respect 
to  Conceptual  Modeling. 

2.  Model  Identification: 

a)  Accommodates  information  related  to  the  identification  of  Conceptual  Modeling: 

(1)  Name. 

(2)  Type. 

(3)  Version. 

(4)  Modification  Date. 

(5)  Security  Classification. 

(6)  Release  Restriction. 

(7)  Purpose. 

(8)  Application  Domain. 

(9)  Description. 

(10)  Use  Limitation. 

3.  Use  History: 

a)  Describes  how  Conceptual  Modeling  was  used. 

4.  Reference: 

a)  Pointer  to  additional  sources  of  info: 

(1)  T.  ex.,  Locations  in  XML  documents. 

(2)  References  to  ontologies. 

5 .  Implementation  Dependencies : 

a)  A  log  of  all  dependencies  determined  during  Conceptual  Modeling  development: 

(1)  T.  ex.,  Domain  ontologies. 

6.  KeyWord: 

a)  Contains  information  about  keywords  (used  for  searching). 

7.  Glyph: 

a)  Contains  an  image  of  Conceptual  Model. 

b)  Sub-parts: 

(1)  Notation. 

(2)  Views. 

(3)  Dynamic. 

(4)  Static. 

II.  Static: 

A.  Role  could  possibly  be  filled  using  DCMF-O,  in  particular  JC3EIDM: 

1 .  Action: 
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a)  Describes  military  actions  on  the  lowest  granular  level  or  higher  level  aggregation. 

2.  Context: 

a)  Context  in  which  action  occurs. 

3.  Reporting: 

a)  Contains  all  data  and  information. 

4.  Rule  of  Engagement: 

a)  Associated  with  actions. 

5 .  Candidate-Target  List: 

a)  Associated  with  actions. 

6.  Objects: 

a)  Type: 

(1)  Static  and  persistent. 

b)  Item: 

(1)  Dynamic  and  likely  to  change  over  time. 

7.  Action  Capability: 

a)  Capability  of  an  object  to  perform  a  function  or  achieve  an  end. 

8.  Location: 

a)  Specific  place  for  any  item  in  the  sphere  of  operations. 

b)  Geometric  shapes  needed  to  plan,  direct,  and  monitor  operations: 

(1)  Related  to  object-item  concept. 

(2)  T.  ex,  Boundaries. 

(3)  Corridors. 

(4)  Restricted  Area. 

(5)  Minefields. 

9.  Affiliation: 

a)  All  objects  possess  an  affiliation: 

(1)  T.  ex  Political  Nation. 

(2)  Ethnic  group. 

III.  Dynamic: 

A.  Role  could  possibly  be  filled  using  DCMF-O,  in  particular  BOM++: 

1 .  Captures  activities,  actions,  and  decisions  performed  by  the  atomic  knowledge  components  of 
the  Conceptual  Model. 

B .  Pattern  of  Interplay: 

1 .  Represented  by  one  or  more  pattern  actions  needed  to  accomplish  a  specific  purpose  or 
capability. 

C.  State  Machine: 

1 .  Describes  the  possible  states  of  the  conceptual  entities  as  well  as  the  transitions  between 
them. 

D.  Entity  Type: 

1 .  Provides  a  mechanism  for  describing  the  types  of  conceptual  entities  used  to  represent  senders 
and  receivers  identified  within  a  Pattern  of  Interplay  and  to  carry  out  the  role  of  conceptual 
entities  identified  within  the  state  machine. 

E.  Event  Type: 

1 .  Provides  a  mechanism  for  describing  the  types  of  conceptual  events  used  to  represent  and 
carry  out: 

a)  Pattern  actions. 

b)  Variations. 

c)  Exceptions. 
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A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

State  machine 

Entity  type 

Event  type 

Pattern  of 
interplay 

Ontology  stack 

Meta  data 

(Action) 

(Context) 

(Reporting) 

(Rules  of 
Engagement) 
(Candidate- 
Target  List) 
(Objects) 

(Action 

Capability) 

(Location) 

(Affiliation) 

(POC) 

(Use  history) 
Reference 
(Implementation 
Dependencies) 

(Key  word) 

(Glyph) 

(Model  ID) 

-Name 

-Type 

-  Version 

-  Modification  date 

-  Security 
Classification 

-  Release  restriction 

-  Purpose 

-  Application 
domain 

-  Description 

-  Use  limitation 

E.2.8  Method:  DRDC  [8] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Elements: 

A.  Entities. 

B.  Entity  Attributes. 

C .  F unctions/Actions . 

D .  Relationships/Interactions . 

II.  Assumptions. 

III.  Functions/Actions. 

IV.  Constraints  (restraints)  /  Bounds  /  Limitations  (restrictions). 

V.  Domain  Specific  Algorithms. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 
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Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Functions/ 

actions 

Elements 

Entity  attributes 

Attributes 

Relationships/ 

interactions 

Assumptions 

Constraints/ 

bounds/ 

limitations 

Domain  specific 
algorithm 

E.2.9  Method:  Entity  Relationship  [9] 

Entity  Relationship  perspectives  are  characterized  by  the  following: 

•  Role  of  an  entity  in  a  relationship  is  the  function  that  it  performs  in  the  relationship. 

•  The  information  about  an  entity  or  a  relationship  is  obtained  by  observation  or  measurement,  and  is 
expressed  by  a  set  of  attribute-value  pairs. 

•  An  attribute  can  be  formally  defined  as  a  function  which  maps  from  an  entity  set  or  a  relationship  set 
into  a  value  set  or  a  Cartesian  product  of  value  sets. 

•  Another  conceptual  approach  is  provided  by  Entity-Relationship  (ER)  Modeling  (ERM)  Although 
ER  models  can  be  useful  once  the  design  process  is  finished,  they  are  less  suitable  for  formulating, 
transforming  or  evolving  a  design.  ER  diagrams  are  further  removed  from  natural  language,  cannot  be 
populated  with  fact  instances,  require  complex  design  choices  about  attributes,  lack  the  expressability 
and  simplicity  of  a  role-based  notation  for  constraints,  hide  information  about  the  semantic  domains 
which  glue  the  model  together,  and  lack  adequate  support  for  formal  transformations.  Many  different 
ER  notations  exist  that  differ  in  the  concepts  they  can  express  and  the  symbols  used  to  express  these 
concepts.  For  such  reasons  we  prefer  ORM  for  conceptual  modeling.  In  addition  to  ORM,  VEA  supports 
IDEF1X  (a  hybrid  of  ER  and  relational  modeling)  as  a  view  of  ORM. 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Entity: 

A.  A  “thing”  which  can  be  distinctly  identified. 

II.  Relationship: 

A.  An  association  among  entities. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Entity 

Attribute/ 
value  pairs 

Attribute/value  pairs 

Relationships 
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E.2.10  Method:  KAMA  [10] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Core  meta-model  (KAMA  Foundation): 

A.  KAMA  Behavior: 

1.  Missions. 

2.  Tasks. 

3.  Activities. 

4.  Events. 

5.  States. 

6.  Data  Items. 

7.  Command/Control  Units. 

B.  KAMA  Relationships. 

C.  KAMA  State  Machine: 

1 .  Expresses  the  behavior  of  a  conceptual  model  entity. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

KAMA  state 
machine 

KAMA 

behavior 

KAMA 

behavior 

Attribute/value  pairs 

KAMA 

relationships 

KAMA  relationships 

E.2.11  Method:  Mind  Maps  [11] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Central  focus  of  an  image  or  graphic  representation  of  the  problem  or  information  being  mapped  is 
placed  in  the  center  of  a  page  (BOI’s  or  Basic  Ordering  Ideas): 

A.  Associate  and  connect  ideas  with  lines,  arrows,  and  symbols: 

1 .  Ideas  are  allowed  to  flow  freely  without  judgment. 

2.  Key  words  are  used  to  represent  ideas. 

3.  One  key  word  is  printed  per  line. 

4.  Key  word  ideas  are  connected  to  the  central  focus  with  lines. 

5.  Color  is  used  to  highlight  and  emphasize  ideas. 

6.  Images  and  symbols  are  used  to  highlight  ideas  and  stimulate  the  mind  to  make  other 
connections. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 
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Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

E.2.12  Method:  Topic  Maps  [12] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Topics: 

A.  Are  related  to  each  other  by  associations,  which  are  typed  n-ary  combinations  of  topics: 

1 .  Associations  are  the  general  form  for  the  representation  of  relationships  between  topics  in  a 
topic  map.  An  association  can  be  thought  of  as  an  n-ary  aggregate  of  topics.  That  is,  an 
association  is  a  grouping  of  topics  with  no  implied  direction  or  order,  and  there  is  no 
restriction  on  the  number  of  topics  that  can  be  grouped  together. 

B.  May  also  be  related  to  any  number  of  resources  by  its  occurrences. 

C.  Represents  information  using: 

1 .  Associations  (representing  relationships  between  topics): 
a)  Each  topic  involved  in  an  association  has  a  role  type. 

2.  Occurrences  (representing  information  resources  relevant  to  a  particular  topic): 

a)  Used  to  represent  or  refer  to  information  about  a  concept  represented  by  a  topic. 

b)  Can  be  used  either  to  store  string  data  within  the  topic  map,  or  to  reference  any  kind  of 
Web-addressable  resource  external  to  the  topic  map. 

II.  Topics  (representing  any  concept): 

A.  A  topic  is  a  machine-processable  representation  of  a  concept: 

1.  Topics  have: 

a)  Four  principal  forms  of  identity. 

b)  Can  have  zero  or  more  of  each  of  these  forms  of  identity,  and  thus  can  be  identified 
within  a  topic  map  system  by  a  number  of  different  ways: 

(1)  Identity  as  a  topic  resource  in  a  serialized  topic  map: 

(a)  When  a  topic  map  is  represented  in  a  serialized  form  for  interchange,  each  topic 
is  assigned  a  URI  identifier  that  is  unique  across  that  topic  map. 

(b)  These  URIs  are  used  principally  for  deserializing  references  between  topics. 

(c)  Such  identifiers  are  referred  to  as  source  locators. 

(2)  Identity  as  a  human-readable  label: 

(a)  Names  act  as  labels  for  human  consumption: 

(i)  Can  be  either  text  or  a  reference  to  some  non-textual  representation 
(for  example,  an  icon,  a  sound  clip,  an  animation  clip,  and  so  on.). 

(a)  Can  have  any  number  of  topic  names. 

(ii)  The  scope  mechanism  allows  for  the  case  of  homonyms  (where  a  single  word 
is  used  to  refer  to  two  or  more  different  concepts). 

(3)  Identity  by  reference: 

(a)  When  a  topic  is  used  to  represent  a  resource  that  already  has  its  own  unique  URI, 
that  URI  can  be  used  as  part  of  the  identity  of  the  topic. 

(b)  Known  as  a  subject  locator  in  the  topic  map  standard. 

(4)  Identity  by  description: 

(a)  Topics  can  be  used  to  represent  a  concept  that  does  not  have  its  own  unique  URI: 
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(i)  Many  of  the  things  that  a  topic  can  represent  could  never  have  a  unique  URI 
because  they  are  not  things  that  a  computer  can  resolve  a  reference  to: 

(a)  For  example,  a  person  may  have  any  number  of  database  records  about 
himself  or  online  biographies  or  pictures,  but  none  of  those  addressable 
resources  are  the  person  -  they  are  merely  some  form  of  descriptor  for 
the  person. 

(ii)  The  resource  that  the  subject  identifier  resolves  to  is  known  as  a  subject 
indicator. 

(b)  Subject  identifiers  (URIs)  identify  the  subject  the  topic  is  about: 

(i)  The  key  difference  between  a  subject  identifier  and  subject  locator  is  that  a 
subject  identifier  requires  human  interpretation  of  a  resource  to  determine  the 
concept  that  a  topic  represents,  whereas  a  subject  locator  simply  points  to  the 
concept  that  the  topic  represents. 

III.  Scope: 

A.  Used  in  the  topic  map  standard  to  refer  to  a  constraint  or  a  context  in  which  something  is  said 
about  a  topic.  The  way  in  which  such  statements  about  topics  are  made  is  by  adding  a  name  to  the 
topic;  specifying  an  occurrence  for  a  topic;  or  creating  an  association  between  topics  (in  which 
case  the  statement  applies  to  all  of  the  topics  in  the  association): 

1 .  Can  be  attached  to  any  name,  occurrence,  or  association  in  a  topic  map  to  qualify  a  statement, 
but  still  express  it. 

2.  Is  defined  by  a  collection  of  topics  that  can  be  assigned  to  a  name,  an  occurrence,  or  an 
association.  The  default  scope  (where  no  set  is  assigned)  is  known  as  the  unconstrained  scope 
and  simply  means  that  the  name,  occurrence,  or  association  is  always  valid. 

IV.  Topic  Merging: 

A.  In  any  given  topic  map,  each  subject  described  by  the  topic  map  must  be  represented  by  one  and 
only  one  topic  in  the  topic  map.  This  means  that  it  is  the  responsibility  of  the  topic  map  processor 
to  attempt  to  identify  the  situation  in  which  two  topics  represent  the  same  subject  and  to  process 
them  so  that  only  one  topic  remains.  This  is  the  process  of  merging. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

E.2.13  Method:  Operational  Conceptual  Modeling  Language  (OCML)  [13] 

Operational  Conceptual  Modeling  Language  has  the  following  attributes: 

•  Description  at:  http://technologies.kmi.open.ac.uk/ocml/; 

•  Allows  the  specification  and  operationalization  of  functions,  relations,  classes,  instances  and  rules;  and 

•  Includes  mechanisms  for  defining  ontologies  and  problem  solving  methods,  the  main  technologies 
developed  in  the  knowledge  modeling  area. 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 
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I.  Relations: 

A.  Allow  the  OCML  user  to  define  labeled  n-ary  relationships  between  OCML  entities. 

II.  Functions: 

A.  Defines  a  mapping  between  a  list  of  input  arguments  and  its  output  argument. 

III.  Classes. 

IV.  Instances. 

V.  Rules: 

A.  Forward:  forward  rule  comprises  zero  or  more  antecedents  and  one  or  more  consequents. 

B.  Backward. 

VI.  Procedures: 

A.  Define  actions  or  sequences  of  actions  which  cannot  be  characterized  as  functions  between  input 
and  output  arguments. 

VII.  Constructs: 

A.  Functional: 

1 .  Specifies  an  object  in  the  current  domain  of  investigation: 

a)  Can  be: 

(1)  Constant. 

(2)  Variable. 

(3)  String. 

(4)  Function  application. 

(5)  Can  also  be  constructed  by  means  of  a  special  term  constructor. 

B.  Control  terms: 

1.  Specify  actions. 

2.  Describe  the  order  in  which  actions  are  executed. 

3.  Can  be  expressed  as: 

a)  Sequential. 

b)  Iterative. 

c)  Conditional  control  structures. 

C.  Logical  expressions. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Classes 

Procedures 

Relations 

Instances 

Functions 

Functional 

constmct 

Rules 

Control  terms 

E.2.14  Method:  Object  Process  Methodology  (OPM)  [14] 

See  for  reference:  http://www.opcat.com/products_opm.htm. 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 
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I.  Object  Process  Diagrams  (OPD): 

A.  Formal  graphic  model. 

II.  Object  Process  Language  (OPL): 

A.  Natural  language  (English  sub-set/controlled  vocabulary)  generated  in  RT  in  response  to 
human  input  in  OPD. 

B.  OPD  are  developed  and  then  OPL  is  generated  from  it. 

III.  Three  building  blocks: 

A.  Objects: 

1 .  Things  that  exist. 

2.  Physical  or  informational  things: 

a)  What  are  the  states  of  the  object? 

b)  Which  processes  create,  destroy,  and  modify  the  object? 

c)  Which  processes  does  it  instrument? 

B.  Processes: 

1.  Things  that  transform  objects  by  changing  their  states  or  creating  or  consuming  objects. 

2.  Processes  are  peers  of  Objects. 

3.  Objects  may  contain  processes  and  processes  may  contain  objects: 

a)  Which  objects  instrument  and  initiate  the  process? 

b)  Which  of  the  three  functionalities  does  it  fulfill:  create,  destroy,  or  modify  the  states 
of  an  object? 

C.  States: 

1.  Lower  level  entities  since  states  are  expressed  inside  of  objects: 

a)  What  object  does  it  belong  to? 

b)  Which  process  triggered  the  change  of  the  state? 

c)  What  are  the  source  and  destination  states? 

IV.  Two  parts  of  OPM  ontology: 

A.  Entities. 

B.  Links,  which  can  be: 

1 .  Structural  -  express  static,  time-independent  relations  between  pairs  of  entities. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Object 

Processes 

Processes 

States 

E.2.15  Method:  Object-Role  Modeling  (ORM)  [15] 

Object  Role  Modeling  may  be  characterized  as  follows: 

•  Early  versions  of  object  role  modeling  were  developed  in  Europe  in  the  mid-1970s  (for  example,  binary 
relationship  modeling  and  Natural  Language  Information  Analysis  Method  (NLIAM)).  The  version 
discussed  here  is  based  on  the  author’s  formalization  of  the  method,  and  incorporates  extensions  and 
refinements  arising  from  research  conducted  in  Australia  and  the  United  States.  The  associated  language 
Formal  Object-Role  Modeling  Language  (FORML)  is  supported  in  Microsoft®  Visio®  for  Enterprise 
Architects  (YEA),  part  of  Visual  Studio®  .NET  Enterprise  Architect. 
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•  The  information  system’s  life-cycle  typically  involves  several  stages:  feasibility  study;  requirements 
analysis;  conceptual  design  of  data  and  operations;  logical  design;  external  design;  prototyping;  internal 
design  and  implementation;  testing  and  validation;  and  maintenance.  ORM’s  Conceptual  Schema  Design 
Procedure  (CSDP)  focuses  on  the  analysis  and  design  of  data.  The  conceptual  schema  specifies  the 
information  structure  of  the  application:  the  types  of  fact  that  are  of  interest;  constraints  on  these 
facts;  and  perhaps  the  derivation  rules  for  deriving  some  facts  from  others. 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 


Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

Conceptual  schema 

E.2.16  Method:  UML  [16] 

Properties  educed  from  examination  of  the  standard  in  accordance  with  the  strategy  outlined  in  Section  E.l 
above  include  the  following: 

I.  Structure  Diagrams: 

A.  Class  Diagram: 

1.  Shows  how  the  different  entities  (people,  things,  and  data)  relate  to  each  other. 

B .  Obj ect  Diagram. 

C.  Component  Diagram: 

1 .  A  physical  view  of  the  system,  meant  to  show  the  dependencies  that  the  software  has  on  the 
other  software  components. 

D.  Composite  Structure  Diagram. 

E.  Package  Diagram. 

F.  Deployment  Diagram: 

1 .  Shows  how  a  system  will  be  physically  deployed  in  the  hardware  environment. 

IT  Behavior  Diagrams: 

A.  Use  Case  Diagram: 

1 .  Illustrates  a  unit  of  functionality  provided  by  the  system. 

B.  Activity  Diagram: 

1 .  Show  the  procedural  flow  of  control  between  two  or  more  class  objects  while  processing  an 
activity. 

C.  State  Machine  Diagram: 

1 .  Models  the  different  states  that  a  class  can  be  in  and  how  that  class  transitions  from  state  to 
state. 

III.  Interaction  Diagrams: 

A.  Sequence  Diagram: 

1.  Shows  a  detailed  flow  for  a  specific  use  case  or  even  just  part  of  a  specific  use  case. 

B.  Communication  Diagram. 

C.  Timing  Diagram. 

D.  Interaction  Overview  Diagram. 

IV.  Other  important  concepts: 

A.  A  UML  profile  is  a  specification  that  does  one  or  more  of  the  following: 

1 .  Identifies  a  sub-set  of  the  UML  meta-model. 
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2.  Specifies  “well-formedness  rules”  beyond  those  specified  by  the  identified  sub-set  of  the 
UML  meta-model. 

3.  “Well-formedness  rule”  is  a  term  used  in  the  normative  UML  meta-model  specification  to 
describe  a  set  of  constraints  written  in  UML’s  Object  Constraint  Language  (OCL)  that 
contributes  to  the  definition  of  a  meta-model  element. 

4.  Specifies  “standard  elements”  beyond  those  specified  by  the  identified  sub-set  of  the  UML 
met-model. 

5.  “Standard  element”  is  a  term  used  in  the  UML  meta-model  specification  to  describe  a 
standard  instance  of  a  UML  stereotype,  tagged  value  or  constraint. 

6.  Specifies  semantics,  expressed  in  natural  language,  beyond  those  specified  by  the  identified 
sub-set  of  the  UML  meta-model. 

7.  Specifies  common  model  elements,  expressed  in  terms  of  the  profile. 

B.  Stereotype: 

1 .  A  stereotype  defines  how  an  existing  meta-class  may  be  extended,  and  enables  the  use  of 
platform  or  domain  specific  terminology  or  notation  in  place  of,  or  in  addition  to,  the  ones 
used  for  the  extended  meta-class. 

2.  A  stereotype  denotes  a  variation  on  an  existing  modeling  element  with  the  same  form  but  with 
a  modified  intent.  Stereotypes  are  effectively  used  to  extend  the  UML  in  a  consistent  manner. 


Language  Unit 

Purpose 

Actions 

(Foundation)  modeling  of  fine-grained  actions 

Activities 

Data  and  control  flow  behavior  modeling 

Classes 

(Foundation)  modeling  of  basic  structures 

Components 

Complex  structure  modeling  for  component  technologies 

Deployments 

Deployment  modeling 

General  Behaviors 

(Foundation)  common  behavioral  semantic  base  and  time  modeling 

Information  Flows 

Abstract  data  flow  modeling 

Interactions 

Inter-object  behavior  modeling 

Models 

Model  organization 

Profiles 

Language  customization 

State  Machines 

Event-driven  behavior  modeling 

Structures 

Complex  structure  modeling 

Templates 

Pattern  modeling 

Use  Cases 

Informal  behavioral  requirements  modeling 

A  table  compiling  the  canonical  allocation  of  conceptual  components  evident  in  the  standard  to  the  vernacular 
conceptual  model  characteristics  reserved  words,  therefore,  is: 
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Using 

Behaviors 

An  Actor 

Actuates 

Events 

Composed  of 
Activities 

Directed  by 
Controls 

Richly  Described 
by  Information 

General 

behaviors 

Classes 

Actions 

Behavior  diagrams 
-  Use  case 
diagram 

Activity  diagram 
State  machine 
diagram 

Structure  diagram 
-  Class  diagram 

Interactions 

Activities 

Interaction 

diagrams 

-  Sequence 
diagrams 

-  Communications 
diagrams 

-  Timing  diagram 

-  Interaction 
overview  diagram 

State  machines 

Profiles 

Stereotypes 

Use  cases 
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F.l  INTRODUCTION 

As  indicated  in  Section  3.2.6  “Standards  Review  and  Evaluation”  of  the  accompanying  text,  the  Team  invested 
significant  effort  reviewing  standards  potentially  relevant  to  conceptual  modeling  in  hopes  of  leveraging  existing 
standards  and  standards  types  to  the  greatest  extent  possible  in  developing  the  best-practice  guidance  contained 
herein. 

An  indication  of  the  scope  and  evaluative  interest  in  such  standards  is  provided  in  Table  F-l  following.  Based 
on  an  initial  review  of  the  standards  indicated  therein,  the  Team  selected  nineteen  (19)  standards  of  particular 
interest  to  conceptual  modeling  and  for  further  analysis  and  commentary. 


Table  F-1:  Standards  with  Applicability  in  NATO  Modeling  and  Simulation  Domain. 


STANDARD 

Standard  Development 
Organization 

Status 

Functional  Area 

Define  Application 
Objectives 

Perform  Conceptual 
Analysis 

Design  Federation 

Design  Simulation 

Develop  Simulation 

Develop  Federation 

Plan,  Integrate  and 

Test  Application 

Execute  Application 

and  Prepare  Outputs 

Analyze  Data  and 

Evaluate  Results 

CMMI 

Camagie 

Mellon 

University 

Published 

Business 

Process 

Management 

X 

X 

BOMs 

SISO 

Published 

Conceptual 

Modeling 

X 

X 

X 

X 

CML 

OneSAF 

PMO 

Published 

Conceptual 

Modeling 

X 

X 

X 

X 

X 

X 

IDEFO 

IEEE 

Published 

Conceptual 

Modeling 

X 

IDEF5 

KBS 

Published 

Conceptual 

Modeling 

X 

X 

X 

X 

X 

OWL-Web 

Ontology 

Language 

W3C 

Published 

Conceptual 

Modeling 

X 

Simulation 
Conceptual 
Modeling  RP 

SISO 

Concept 

Conceptual 

Modeling 

X 

X 

X 

UML 

OMG 

Published 

Conceptual 

Modeling 

X 

X 

X 

X 

DCMF 

Open 

Source 

Published 

Data 

Engineering 

X 

X 

X 

IDEF1X 

NIST 

Published 

Data 

Engineering 

X 

X 

X 

RTO-TR-MSG-058 


F-1 


ANNEX  F  -  STANDARDS 


ORGANIZATION 


STANDARD 

Standard  Development 
Organization 

Status 

Functional  Area 

Define  Application 

Objectives 

Perform  Conceptual 

Analysis 

Design  Federation 

Design  Simulation 

Develop  Simulation 

Develop  Federation 

Plan,  Integrate  and 

Test  Application 

Execute  Application 

and  Prepare  Outputs 

Analyze  Data  and 

Evaluate  Results 

OKBC 

DARPA 

Published 

Data 

Engineering 

X 

X 

X 

RDF 

World- 
Wide- Web 
Consortium 
(W3C) 

Published 

Data 

Engineering 

X 

X 

X 

X 

XML 

W3C 

Published 

Data 

Engineering 

X 

X 

X 

C-BML 

SISO 

Draft 

Data 

Mediation 

X 

X 

X 

X 

X 

CMSD 

SISO 

Draft 

Data 

Mediation 

X 

X 

X 

X 

JC3IEDM 

MIP 

Published 

Data 

Mediation 

X 

X 

X 

X 

OpenFlight 

MultiGen- 

Paradigm 

Published 

Data 

Mediation 

X 

X 

X 

SEDRIS 

ISO 

Published 

Data 

Mediation 

X 

X 

X 

X 

X 

DFAD 

U.S.  DoD 

Published 

Data 

Production 

Format 

X 

X 

X 

X 

X 

DTED 

U.S.  DoD 

Published 

Data 

Production 

Format 

X 

X 

X 

X 

X 

DEVS 

SISO 

Concept 

M&S- 

Miscellaneous 

X 

X 

SCORM  Sim 

SISO 

Concept 

M&S- 

Miscellaneous 

X 

X 

X 

X 

X 

X 

SRML 

SISO 

Draft 

M&S- 

Miscellaneous 

X 

X 

HLA  FEDEP 

SI  SO/IEEE 

Published 

M&S-Process 

X 

X 

X 

X 

X 

X 

X 

X 

X 

SEDEP 

EUCLID 

Published 

M&S-Process 

X 

X 

X 

X 

X 

X 

X 

X 

X 
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STANDARD 

Standard  Development 
Organization 

Status 

Functional  Area 

Define  Application 

Objectives 

Perform  Conceptual 

Analysis 

Design  Federation 

Design  Simulation 

Develop  Simulation 

Develop  Federation 

Plan,  Integrate  and 

Test  Application 

Execute  Application 

and  Prepare  Outputs 

Analyze  Data  and 

Evaluate  Results 

Link  1 1 
Simulations 

SISO 

Draft 

M&S- 

Representation 

X 

X 

X 

Link  16 
Simulations 

SISO 

Published 

M&S- 

Representation 

X 

X 

X 

MOD-5/S  IFF 

SISO 

Concept 

M&S- 

Representation 

X 

X 

X 

RPR  FOM 

SISO 

Published 

M&S- 

Representation 

X 

X 

X 

X 

MSDL 

SISO 

Draft 

M&S- 

Scenarios 

X 

X 

X 

X 

X 

CSPI 

SISO 

Draft 

M&S- 

Simulation 

Inter¬ 

operability 

X 

DIS 

SISO/IEEE 

Published 

M&S- 

Simulation 

Inter¬ 

operability 

X 

X 

X 

X 

X 

HLA 

SISO/IEEE 

Published 

M&S- 

Simulation 

Inter¬ 

operability 

X 

(OMT) 

X 

(OMT) 

X 

X 

X 

X 

TENA 

US  DoD 

Published 

M&S- 

Simulation 

Inter¬ 

operability 

X 

X 

X 

X 

X 

X 

CORBA 

OMG 

Published 

Software 

Engineering 

X 

X 

X 

X 

MDA 

OMG 

Published 

Software 

Engineering 

X 

X 

X 

X 

RUP 

IBM 

Published 

Software 

Engineering 

X 

X 

X 

X 

Software  QA 
Plans (1220) 

IEEE 

Published 

Software 

Engineering 

X 

X 
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ORGANIZATION 


STANDARD 

Standard  Development 
Organization 

Status 

Functional  Area 

Define  Application 

Objectives 

Perform  Conceptual 

Analysis 

Design  Federation 

Design  Simulation 

Develop  Simulation 

Develop  Federation 

Plan,  Integrate  and 

Test  Application 

Execute  Application 

and  Prepare  Outputs 

Analyze  Data  and 

Evaluate  Results 

Software  Reuse 
Data  Model 
(1420) 

IEEE 

Published 

Software 

Engineering 

X 

X 

X 

UML 

OMG 

Published 

Software 

Engineering 

X 

X 

X 

X 

DoD 

Architecture 

Framework 

US  DoD 

Published 

Systems 

Engineering 

X 

X 

X 

MOD 

Architecture 

Framework 

UK  MOD 

Published 

Systems 

Engineering 

X 

X 

X 

SysML 

OMG/INC 

OSE 

Published 

Systems 

Engineering 

X 

X 

X 

X 

GM-V&V 

SISO 

Concept 

V&V 

X 

X 

X 

X 

X 

X 

X 

REVVA1 

EUCLID 

Published 

V&V 

X 

X 

X 

X 

X 

X 

X 

X 

X 

V&V 

Information 

Exchange 

ITOP 

Published 

V&V 

? 

X 

X 

VV&A 

Overlay  to 
FEDEP 

SI  SO/IEEE 

Draft 

V&V 

X 

X 

X 

X 

X 

X 

X 

VV&A  RPG 

US  DoD 

Published 

V&V 

X 

X 

X 

X 

X 

X 

X 

X 

X 

F.2  RELEVANT  STANDARDS  CHARACTERIZATION 

In  the  tables  that  follow,  selected  standards  identified  in  Table  F-l  above  are  described  in  considerable  detail. 
The  intention  of  the  Task  Group  in  providing  this  description  is  to  provide  users  of  the  best-practice  guidance 
contained  formally  in  Annexes  G  and  H  below  to  leverage  to  best  advantage  -  contingent  enterprise  and 
technical  constraints  and  motivations  -  some  of  the  several  standards  that  are  known  by  the  Group  to  be  relevant 
to  both  the  specification  of  conceptual  models  themselves  and  to  the  expression  of  best-practice  within  enterprise 
contexts. 

Standards  described  in  detail  in  the  tables  following  include: 

•  Based  Object  Model  (BOM). 

•  Conceptual  Modeling  Language  (CML). 

•  Capability  Maturity  Model  Integration  (CMMI). 

•  Defence  Conceptual  Modeling  Framework  (DCMF). 

•  Discrete  Event  Systems  (DEVS). 
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•  Department  of  Defense  Architecture  Framework  (DoDAF). 

•  Generic  Methodology  for  Verification,  Validation  (GM-VV). 

•  Integrated  Definition  Methods  (IDEFO). 

•  Integrated  Definition  Methods  (IDEF5). 

•  Joint  Command  Control  Communications  Information  Exchange  Data  Model  (JC3IEDM). 

•  Kernel  Meta  Meta  Model  (KM3). 

•  Model  Driven  Architecture  (MDA). 

•  NATO  Architecture  Framework  (NAF). 

•  Open  Knowledge  Base  Connectivity  (OKBC). 

•  Web  Ontology  Language  (OWL). 

•  Resource  Description  Framework  (RDF). 

•  Rational  Unified  Process  (RUP). 

•  Systems  Modeling  Language  (SysML). 

•  Unified  Modeling  Language  (UML). 


Table  F-2:  Based  Object  Model  (BOM). 


ATTRIBUTE 

COMMENTS 

Organization: 

Simulation  Interoperability  Standards  Organization  (SISO) 

Definition: 

The  BOM  is  a  component-based  standard  for  describing  a  reusable  piece  part  of 
a  federation  or  an  individual  federate.  Specifically,  the  BOM  specification  offers 
ontology  for  characterizing  elements  of  a  simulation  and  relationships  among 
conceptual  entities  within  a  simulation  environment  as  a  language  neutral 
interface.  BOMs  can  be  used  to  document  the  interface  for  one  or  more  of  the 
following  piece  part  elements:  1)  Object  classes;  2)  Interaction  classes;  3)  Patterns 
of  interplay;  4)  State  machines;  and  5)  Events.  BOMs  provide  developers  and  users 
a  modular  approach  for  defining  and  adding  new  capabilities  to  a  federate  or 
federation,  and  in  quickly  composing  object  models  such  as  HLA  FOMs  and 

SOMs  through  BOM  Assemblies. 

Intended  Use: 

Base  Object  Models  (BOMs)  provide  a  key  mechanism  in  facilitating 
interoperability,  reuse,  and  composability.  BOMs  are  specifically  identified  in  the 
IEEE  1516.3  HLA  Federation  Development  and  Execution  Process  (FEDEP)  as 
a  potential  facilitator  for  providing  reusable  model  components  used  for  the  rapid 
construction  and  modification  of  federates  and  federations.  The  open 
standardization  of  BOM  representations  is  considered  essential  for  encouraging 
their  development,  distribution  and  use.  The  BOM  concept  is  based  on  the 
assumption  that  piece-parts  of  simulations  and  federations  can  be  extracted  and 
reused  as  modeling  building-blocks  or  components. 
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ORGANIZATION 


ATTRIBUTE 

COMMENTS 

Intended  Use 
(cont’d): 

The  interplay  within  a  simulation  or  federation  can  be  captured  and  characterized 
in  the  form  of  reusable  patterns.  These  patterns  of  simulation  interplay  are 
sequences  of  events  between  simulation  elements.  The  implementation  of  the 
pattern  using  HLA  object  model  constructs  is  also  captured  in  the  BOM. 

Community 
of  Usage: 

Primary  in  Military  Modeling  and  Simulation  domain  but  even  across  government 
and  non-government  applications  worldwide. 

Significant 

Attributes: 

The  BOM  framework  as  documented  in  the  BOM  specification  and  the  BOM 
guidance  document  is  intended  to  influence  the  following  six  capabilities  within 
the  M&S  community:  Interoperability  -  The  application  of  Extensible  Markup 
Language  (XML)  and  XML  Schemas  prescribed  for  BOMs  provides  a  mechanism 
for  defining  and  validating  context,  and  facilitates  understanding  of  the  data  being 
exchanged.  Furthermore,  the  flexibility  offered  by  BOMs  allows  for  greater 
application  of  simulation  interoperability  within  other  domains.  Reusability  - 
The  Meta  data  cataloged  within  a  BOM  such  as  intent-of-use,  integration  history, 
behavioral  information,  and  potential  visual  information  will  facilitate  greater 
reuse  of  components.  Composability  -  BOMs  will  facilitate  the  ability  to  rapidly 
compose  simulations  and  simulation  environments  both  statically  (design  time) 
and  dynamically  (at  run-time).  Adaptability  -  Mega-BOMs  produced  by  BOM 
compositions  can  be  used  to  represent  the  standard  data  exchange  interface  for 
systems  and  simulations.  Aggregation  -  The  application  of  BOMs  can  be  used  for 
supporting  two  types  of  aggregation:  Pattern  Aggregation  and  Entity  Aggregation. 
Pattern  Aggregations  reflect  the  coupling  of  interface  groupings  that  can  be 
identified  prior  to  an  exercise.  Entity  Aggregations  reflect  the  coupling  of  multiple 
entities  into  a  single  inclusive  group,  which  can  be  accomplished  during  a 

Federation  Execution  (FEDEX).  Multi-resolution  Models  -  At  the  Federate 
Capability  Level,  BOMs  can  be  used  to  represent  the  behavior  states  needed  for 
modeling  a  conceptual  entity  of  one  or  more  patterns  of  interplay.  Federates  can 
choose  from  an  assortment  of  BOM  Component  Implementations  (BCIs)  of 
varying  resolutions  which  can  be  swapped  out  dynamically  during  an  exercise, 
assuming  the  proper  precautions  are  taken  to  ensure  validity  and  consistency. 

Relevance  to 
Our  Work: 

See  FOI-R — 2363 — SE  (BOM  and  DCMF),  BOM++,  a  Semantically  Enriched 
BOM. 

Relevance  of  Form 
for  Our  Product 
Specification: 

High: 

♦  Its  Meta  data  port  (Model  Identification)  can  be  re-used. 

♦  BOM  fulfils  some  of  basic  requirements  on  a  Conceptual  model  such  as;  reusability 
composability  and  syntactic  interoperability. 

♦  BOM  structure  and  mechanism  (like  pattern  of  interplay  and  state  Machine) 
as  well  as  BOM  Assembly  can  be  source  of  inspiration. 

References: 

http://www.boms.info/.  “Simulation  Interoperability  Standards  Organization 
(SISO)  Base  Object  Model  (BOM)  Template  Specification  SISO-STD-003-2006”, 

3 1  March  2006  Copyright  ©  2004  -  2006  by  the  Simulation  Interoperability 
Standards  Organization,  Inc.,  P.O.  Box  781238,  Orlando,  FL  32878-1238,  USA. 
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ATTRIBUTE 

COMMENTS 

References 

(cont’d): 

Simulation  Interoperability  Standards  Organization  (SISO)  Guide  for  Base  Object 
Model  (BOM)  Use  and  Implementation  SISO-STD-003.0  DRAFT- V0.12, 

26  October  2005,  Prepared  by:  SISO  Base  Object  Model  Product  Development 
Group  Keywords:  Automation,  Behavior,  BOM,  Components,  Composability, 
Conceptual  Model,  FEDEP,  Interoperability,  Meta  data,  Patterns,  Requirements, 
Reuse  Copyright  ©  2004  -  2005  by  the  Simulation  Interoperability  Standards 
Organization,  Inc.,  P.O.  Box  781238,  Orlando,  FL  32878-1238,  USA. 

Table  F-3:  Conceptual  Modeling  Language  (CML). 

ATTRIBUTE 

COMMENTS 

Organization: 

U.S.  Army,  OneSAF  Program 

Definition: 

CML  is  the  OneSAF  conceptual  modeling  language. 

Community 
of  Usage: 

CML  is  used  within  the  OneSAF  development  enterprise  as  an  implementation 
independent  and  computationally  amenable  tool  to  increase  efficiency  and  security 
of  transformation  of  information  about  the  real  world  into  simulation 
computational  structures. 

Significant 

Attributes: 

CML  consists  of  meta-class  components  and  inter  class  relationships  which,  when 
instantiated,  constitute  a  pictorial  and  text  specification  of  the  military  mission 
space  conceptual  model.  The  existence  of  well-defined  component  class  types, 
and  intended  interclass  relationships  provides  a  meta  model,  whereby  the 
conceptual  model  practitioner  may  instantiate  conceptual  model  artefacts  that  will 
be  reduced  to  computational  implementation  in  accordance  with  the  pre-existing 
correlations  between  conceptual  model  components  and  computational  component 
artefacts.  CML  class  and  relationships  were  expressly  selected  to  facilitate 
representation  of  military  mission-space  scenarios.  The  use  of  CML  has  been 
observed  to  yield  the  following  benefits:  “1)  improves  KAKE  and  developer 
productivity;  2)  provides  a  common  frame  of  reference  for  all  shareholders; 

3)  minimizes  requirements  creep  by  limiting  KAKE  to  relevant  issues;  and 

4)  provides  a  sufficiently  detailed  description  of  the  modeling  solution  to  minimize 
misinterpretations  and  reinterpretations  of  the  requirements.” 

Relevance  to 
Our  Work: 

CML  and  its  associated  employment  process  are  ostensibly  highly  relevant  to  the 
subject  effort,  having  been  specifically  designed  to  serve  for  conceptual  model 
specification  for  military  models  and  simulations.  The  language  further  has  been 
used  and  tailored/optimized  to  this  purpose  in  context  of  the  OneSAF  simulation 
development  environment.  Specializations  within  CML  related  to  capturing 
military  mission  space  representation  are  specifically  relevant  to  the  current  work. 
On  the  other  hand,  language  features  and  associated  process  specializations  that 
are  peculiar  to  OneSAF  simulation  representation  and/or  implementation  paradigm 
(such  as  simulation  time  advance  mechanization,  data  modularization  protocols, 
object  class  declarations  and  visibility,  etc.)  are  likely  not  suitable  for  the  present 
effort. 
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ORGANIZATION 


ATTRIBUTE 

COMMENTS 

Relevance  to  Our 
Work  (cont’d): 

(NOTE  that  notwithstanding  the  assertion  that  CMS  is  “implementation 
independent”,  several  features  -  many  implicit  in  the  CML  itself  -  seem  to  entail 
implementation-specific  presumption.) 

Relevance  of  Form 
for  Our  Product 
Specification: 

Notational  form  for  within  CML  is  suggestive  and  relevant  in  many  ways  for 
military  mission  space  representation.  On  the  other  hand,  the  notation  is  not  either 
an  industry  standard  nor  does  it  evidently  support  translation  to  alternative 
notations.  It  is,  in  fact  particularly  specific  to  time  management,  data  flow, 
and  control  flow  specifically  elected  from  a  wider  range  of  options  for  use  in 
OneSAF  simulation  implementation.  The  notation  as  -is  is  not  suitable  for  use  in 
the  documents  resulting  from  this  task.  It  may  be  appropriate  and  sufficient  as  a 
notation  for  implementation  of  the  best-practice  guidance  being  developed, 
if-and-only-if  its  intended  application  environment  is  sufficiently  similar  to  that 
of  OneSAF. 

References: 

“Conceptual  Modeling  in  OneSAF  Software  Development”,  briefing  provided  by 
Greg  Tackett  in  cooperation  with  the  U.  S.  Army  OneSAF  Program  Office. 

Table  F-4:  Capability  Maturity  Model  Integration  (CMMI). 

ATTRIBUTE 

COMMENTS 

Organization: 

Carnegie  Mellon,  Software  Engineering  Institute  (SEI) 

Definition: 

CMMI  is  not  a  process  (Ml  level).  It  is  a  process  improvement  approach 
(M2  level)  that  provides  organizations  with  the  essential  elements  of  effective 
processes. 

Intended  Use: 

It  can  be  used  to  guide  process  improvement  across  a  project,  a  division,  or  an 
entire  organization.  CMMI  helps  integrate  traditionally  separate  organizational 
functions,  set  process  improvement  goals  and  priorities,  provide  guidance  for 
quality  processes,  and  provide  a  point  of  reference  for  appraising  current 
processes.  Two  models  exist.  The  CMMI  for  Development  is  a  reference  model 
that  covers  the  development  and  maintenance  activities  applied  to  both  products 
and  services.  Organizations  from  many  industries,  including  aerospace,  banking, 
computer  hardware,  software,  defence,  automobile  manufacturing,  and 
telecommunications,  use  CMMI  for  Development.  This  document  is  a  reference 
model  that  covers  the  acquisition  of  needed  capabilities.  Capabilities  are  acquired 
in  many  industries,  including  aerospace,  banking,  computer  hardware,  software, 
defence,  automobile  manufacturing,  and  telecommunications.  All  these  industries 
can  use  CMMI-ACQ. 

Community 
of  Usage: 

It  is  difficult  to  quantify  how  many  organizations  have  adopted  CMMI  because 
any  organization  can  use  CMMI  for  process  improvement  without  having  to 
register  with  the  SEI  or  otherwise  identify  themselves  to  the  public. 
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ATTRIBUTE 

COMMENTS 

Community  of 
Usage  (cont’d): 

However,  there  have  been  over  55,000  people  who  have  attended  Introduction  to 
CMMI  training,  and  CMMI  has  been  adopted  in  many  industries  (e.g.,  software, 
finance,  and  manufacturing)  in  countries  around  the  world  (e.g.,  United  States, 
Australia,  Japan,  Brazil,  and  Russia). 

Significant 

Attributes: 

The  CMMI  model  is  composed  of  these  main  components:  process  areas,  goals 
and  practices.  It  also  includes  other  components  such  as  notes,  examples, 
amplifications  (domain  specific  notes  and  examples)  and  references.  Some 
components  are  required,  other  are  expected  or  informative.  A  process  area  is  a 
cluster  of  related  practices  in  an  area  that,  when  implemented  collectively,  satisfy 
a  set  of  goals  considered  important  for  making  improvement  in  that  area. 

A  specific  goal  describes  the  unique  characteristics  that  must  be  present  to  satisfy 
the  process  area.  Generic  goals  are  called  “generic”  because  the  same  goal 
statement  applies  to  multiple  process  areas.  A  generic  goal  describes  the 
characteristics  that  must  be  present  to  institutionalize  the  processes  that  implement 
a  process  area  A  specific  practice  is  the  description  of  an  activity  that  is  considered 
important  in  achieving  the  associated  specific  goal.  The  specific  practices  describe 
the  activities  that  are  expected  to  result  in  achievement  of  the  specific  goals  of  a 
process  area.  Generic  practices  are  called  “generic”  because  the  same  practice 
applies  to  multiple  process  areas.  A  generic  practice  is  the  description  of  an 
activity  that  is  considered  important  in  achieving  the  associated  generic  goal. 

A  generic  practice  elaboration  appears  after  a  generic  practice  in  a  process  area  to 
provide  guidance  on  how  the  generic  practice  should  be  applied  uniquely  to  the 
process  area.  A  sub-practice  is  a  detailed  description  that  provides  guidance  for 
interpreting  and  implementing  a  specific  or  generic  practice  The  typical  work- 
products  are  sample  output  from  a  specific  practice.  Levels  are  used  in  CMMI  to 
describe  an  evolutionary  path  recommended  for  an  organization  that  wants  to 
improve  the  processes  it  uses  to  develop  and  maintain  its  products  and  services. 
CMMI  supports  two  representations.  The  staged  representation  (maturity  levels) 
offers  a  systematic  way  to  approach  process  areas  one  stage  at  a  time.  Achieving 
each  stage  ensures  that  an  adequate  process  infrastructure  has  been  laid  as  a 
foundation  for  the  next  stage.  In  the  continuous  representation  (capability  levels), 
an  organization  can  choose  to  improve  different  processes  at  different  rates. 

A  CMMI  level  can  be  officially  certified  following  a  rating  activity  of  appraisals. 
The  Standard  CMMI  Appraisal  Method  for  Process  Improvement  (SCAMPI) 
provides  benchmark  quality  ratings  relative  to  CMMI  models. 

Relevance  to 
Our  Work: 

Since  the  CMMI  models  have  been  designed  in  a  generic  manner  to  improve 
processes,  some  of  its  components  (process  areas,  goals,  practices,  etc.)  are 
directly  applicable  to  our  conceptual  modeling  process  guidelines.  The  CMMI  for 
Development  is  privileged  because  M&S  is  a  developmental  activity  within  the 
targeted  organizations. 
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ORGANIZATION 


ATTRIBUTE 

COMMENTS 

Relevance  to  Our 
Work  (cont’d): 

The  notion  of  maturity  levels  is  also  very  useful  to  scale  the  Conceptual  Model 
process  specification  to  various  organizational  needs  and  to  guide  them  toward  our 
strategic  vision  (Level  5).  This  representation  is  privileged  because  it  is  easier  to 
understand. 

Relevance  of  Form 
for  Our  Product 
Specification: 

The  M2  level  of  language  of  the  CMMI  makes  it  appropriate  to  serve  as  an 
example  for  our  Conceptual  Model  Process  Spec. 

References: 

http://www.sei.CMu.edu/CMmi/,  CMMI  for  Development,  Version  1.2,  CMMI 
Product  Group,  Technical  Report,  CMU/SEI-2006-TR-008,  August  2006,  573  pp. 

Table  F-5:  Defence  Conceptual  Modeling  Framework  (DCMF). 

ATTRIBUTE 

COMMENTS 

Organization: 

FOI  -  Swedish  Defence  Research  Agency 

Definition: 

DCMF  is  a  framework  developed  to  understand  and  describe  activities  and 
processes  in  military  operations.  These  descriptions  will  then  be  the  foundation  for 
developing  conceptual  models  in  a  formal  way.  Those  models  are  primarily  used 
for  simulation  model  development. 

The  framework  consists  of  a  number  of  components  which  together  support 
developers  in  the  task  of  creating  high  quality  conceptual  models  out  of 
unstructured  data.  Examples  of  Framework’s  components  are  a  specified  modeling 
process,  ontologies  and  specifications  of  the  format  of  the  models. 

Intended  Use: 

The  overall  objectives  for  DCMF  is  to  capture  authorized  knowledge  of  military 
operations;  to  manage,  model  and  structure  the  obtained  knowledge  in  an 
unambiguous  way;  and  to  preserve  and  maintain  the  structured  knowledge  for 
future  use  and  reuse.  The  premier  aim  of  doing  so  is  to  enable  semantic  and 
substantive  interoperability  of  the  future  simulation  models  built  on  these 
descriptions. 

Another  long-term  goal  with  DCMF  is  reusability  which  will  reduce  costs  and 
enhance  the  quality  in  the  development  of  conceptual  models.  Our  vision  is  that 
DCMF  will  evolve  enough  to  become  a  standard  for  the  development  of  simulation 
models  within  the  Swedish  Armed  Forces. 

Community 
of  Usage: 

FOI  and  Swedish  Armed  Forces. 

Significant 

Attributes: 

MSMs  -  Mission  Space  Models  -  which  are  the  final  result  of  the  DCMF  process, 
and  the  kernel  of  both  DCMF  and  CMMS  they  are  defined  as  simulation  and 
implementation  independent  functional  descriptions  of  the  real-world  processes, 
entities,  and  environmental  factors  associated  with  a  particular  set  of  missions. 
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ATTRIBUTE 

COMMENTS 

Significant 

Attributes 

(cont’d): 

These  descriptions  would  be  able  to  serve  as  a  frame  of  reference  for  simulation 
development  by  capturing  the  basic  information  about  the  important  entities 
involved  in  any  mission,  and  their  key  actions  and  interactions.  It  is  to  say  these 
are  for  all  stakeholders  in  the  M&S  process  a  common  description  of  what  is  to  be 
simulated  and  serve  as  a  bridge  between  the  military  experts  and  the  developers. 

The  military  experts  own  the  mission  process  and  are  an  authoritative  source  when 
validating  the  content  of  the  conceptual  models.  MSMs  also  serve  as  a  platform  for 
communication  among  stakeholders  working  with  these  simulation  models. 

Already  within  the  Modeling  and  Simulation  Master  Plan  (MSMP)  developed  by 
the  US  DoD  the  CMMS  concept  was  presented  as  an  essential  requirement  for 
interoperability  and  reusability  of  knowledge  in  the  military  domain.  On  top  of 
that  the  DCMF  initiative  has  tried  to  put  some  more  concrete  requirements. 

To  summarize,  the  DCMF  requirements  for  how  the  final  conceptual  models 
should  be  are  as  follows: 

•  Well  documented; 

•  Readable  and  usable  for  a  person  as  well  as  a  machine; 

•  Composable; 

•  Traceable  the  whole  way  back  to  the  original  sources;  and  finally 

•  Useable  as  a  basis  for  simulation  models. 

Relevance  to 
Our  Work: 

The  framework  provides: 

•  A  definition  for  a  Conceptual  Model; 

•  A  process  for  delivering  high  quality  Conceptual  Models; 

•  A  structure/template  for  the  procedure  Conceptual  Models; 

•  A  formalism  over  Conceptual  Models; 

•  A  list  of  potential  stakeholder;  and 

•  A  list  of  different  roles  and  their  interactions. 

Relevance  of  Form 
for  Our  Product 
Specification: 

At  least  a  source  of  inspiration  and  an  example  of  the  way  we  can  develop  the 
Defence  Conceptual  Modeling  Framework. 

References: 

FOI-R—  1754-SE. 

FOI-R — 2362— SE. 

05F-SIW-038. 

Table  F-6:  Discrete  Event  Systems  (DEVS). 


ATTRIBUTE 

COMMENTS 

Organization: 

Arizona  Center  for  Integrative  Modeling  and  Simulation  (ACIMS) 
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ORGANIZATION 


ATTRIBUTE 

COMMENTS 

Definition: 

Discrete  Event  Systems  (DEVS)  formalism  specification  is  a  notation  language 
(Ml  level)  specific  to  discrete  event  models. 

Intended  Use: 

EVS  is  to  be  used  as  a  standard  notation  for  discrete  event  system  Modeling. 

Community 
of  Usage: 

Discrete  event  system  modellers. 

Significant 

Attributes: 

The  DEVS  model  components  are:  inputs,  outputs,  states  and  events. 

Relevance  to 
Our  Work: 

DEVS  is  not  directly  applicable  to  MSG-058  work  because  it  specifies  a  Modeling 
language  (Ml  level)  instead  of  providing  guidance  on  how  to  specify  a  language. 
Furthermore,  it  is  specific  to  the  discrete  event  formalism,  which  makes  it  a 
Modeling  language  of  a  lower  level  of  abstraction  that  is  already  well  defined  and 
outside  the  scope  of  the  Task  Group.  However,  DEVS  could  be  stated  as  an 
example  of  well-known  low-level  conceptual  modeling  language. 

Relevance  of  Form 
for  Our  Product 
Specification: 

Due  to  its  scoped  target,  the  DEVS  specification  can  be  very  formal.  Its  form  is  not 
appropriate  to  the  MSG-058  product  specification. 

References: 

ACIMS  -  www.acims.arizona.edu. 

DEVS  Standardization  Group  -  http://www.sce.carleton.ca/faculty/wainer/standard/. 

Table  F-7:  Department  of  Defense  Architecture  Framework  (DoDAF). 


ATTRIBUTE 

COMMENTS 

Organization: 

DoD  U.S. 

Definition: 

Department  of  Defense  Architecture  Framework. 

Intended  Use: 

The  DoDAF  defines  a  standard  way  to  organize  an  Enterprise  Architecture  (EA) 
or  systems  architecture  into  complementary  and  consistent  views.  All  major  U.S. 
Government  Department  of  Defense  (DoD)  weapons  and  information  technology 
system  procurements  are  required  to  develop  and  document  an  EA  using  the  views 
prescribed  in  the  DoDAF.  While  it  is  clearly  aimed  at  military  systems,  DoDAF 
has  broad  applicability  across  the  private,  public  and  voluntary  sectors  around  the 
world,  and  represents  only  one  of  a  large  number  of  systems  architecture 
frameworks.  It  is  especially  suited  to  large  systems  with  complex  integration  and 
interoperability  challenges,  and  is  apparently  unique  in  its  use  of  “operational 
views”  detailing  the  external  customer’s  operating  domain  in  which  the  developing 
system  will  operate. 

Community 
of  Usage: 

All  major  U.S.  Government  Department  of  Defense  (DoD)  procurements. 
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ATTRIBUTE 

COMMENTS 

Significant 

Attributes: 

DoDAF  views  are  organized  into  four  basic  view  sets: 

•  Overarching  All  View  (AV); 

•  Operational  View  (OV); 

•  Systems  View  (SV);  and 

•  Technical  Standards  View  (TV). 

It  does  not  prescribe  a  modeling  language  (e.g.,  UML). 

April  23,  2007:  Version  1.5  was  released,  ‘Volume  I:  Definitions  and  Guidelines’ 

(46  pages),  ‘Volume  II:  Product  Descriptions’  (284  pages),  and  ‘Volume  III: 
Architecture  Data  Description’  (223  pages). 

Relevance  to 
Our  Work: 

Framework  provides  a  potential  definition  for  a  conceptual  model.  It  contains: 

•  An  overall,  high-level  scenario  (OV-1)  -  includes  scope,  purpose; 

•  Connectivity  between  and  within  systems  (OV-2); 

•  Information  exchanged  during  system  connectivity  (OV-3); 

•  Systems  used  by  the  organizations  to  perform  the  activities  (OV-3); 

•  Organizations  performing  the  activities  (OV-4); 

•  Activities  performed  in  the  scenario  (V-6);  and 

•  Data  elements  contained  in  information  exchanges  (OV-7). 

Relevance  of  Form 
for  Our  Product 
Specification 

The  Task  Group  did  not  employ  DoDAF  schemas  explicitly  in  its  product 
specification  on  the  grounds  that  while  the  DoDAF  views,  usage,  and  associated 
tools  may  well  support  practitioner’s  needs,  the  approach  is  inherently  specific 
with  respect  to  representational  schemas  required,  and  peculiar  in  its  endorsement 
by  one  Member  Nation  represented  on  the  Task  Group.  The  degree  to  which 
practitioners  following  the  best-practice  guidance  herein  use  DoDAF  conventions 
is  considered  elective  particularly  with  respect  to  the  consequences  of  their  efforts 
and  the  nature  of  military  (or  other)  simulations’  conceptual  models. 

References: 

DoDAF  Promulgation  Memo  Feb  9,  2004  -  DODAF  Policy  Directive  mandates 
use,  all  Architectures  approved  after  12/01/03  must  be  DODAF  compliant. 

http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_I.pdf,  DoDAF  1 .5 
Volume  1]  -  Provides  definitions,  guidelines,  background  material. 

http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_II.pdf,  DoDAF  1 .5 
Volume  2]  -  Describes  each  architecture  product. 

http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_III.pdf,  DoDAF  1 .5 
Volume  3]  -  Provides  the  architecture  data  description.  DoDAF  1.0  Deskbook  - 
Provides  supplementary  “how  to”  information  relating  to  architectures.  The 

DODAF  architecture  documents  were  updated  on  April  23,  2007  to  version  1.5. 
Currently  the  Deskbook,  which  is  from  February  9,  2004,  has  not  been  updated. 
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Table  F-8:  Generic  Methodology  for  Verification  and  Validation  (GM-V&V). 


ATTRIBUTE 

COMMENTS 

Organization: 

NMSG-073 

Definition: 

Standards:  GM-VV  to  support  acceptance  of  Models,  Simulations,  and  Data. 

Intended  Use: 

The  GM-V&V  aims  to  provide  a  common  generic  framework  for  making  formal 
and  well-balanced  acceptance  decisions  on  a  specific  usage  of  models,  simulations 
(both  legacy  and  new  development)  and  data.  Moreover,  the  GM-V&V  comprises 
of  methods,  practices  and  techniques  that  capture  the  interplay  between  the 
allocation  of  V&V  resources  (costs,  etc.),  stakeholders’  needs,  and  M&S  usage 
risks  in  decision-making.  The  GM-V&V  is  based  on  a  three  pillar-view;  product, 
process  and  organization.  The  objective  of  a  GM-V&V  based  project  is  to  make 
well-informed  acceptance  decisions  on  a  specific  usage  of  a  model,  simulations 
or  data  based  upon  a  precise  and  formal  argumentation.  GM-V&V  adopts  a  goal- 
driven  approach  to  derive  acceptance  criteria  from  the  stakeholders’  purpose, 
and  subsequently  derives  evidence  criteria  and  associated  tests  from  those 
acceptance  criteria.  This  goal-driven  approach  is  considered  in  a  context  of  the 

M&S  system  intended  use,  development,  use-risk,  V&V  cost-benefits  and  project 
constraints.  The  goal-based  hierarchical  derivation  of  criteria  is  on  the  one  hand 
well  suited  for  use  in  compliance  with  (an  adapted)  ISO/IEC  9126,  and  on  the 
other  hand  clearly  focuses  on  the  special  elements  needed  for  measuring  the 
quality  of  the  Modeling  part.  The  hierarchical  derivation  starts  with  the  goal  to 
show  that  the  Conceptual  Model  provides  utility  for  its  use  in  the  development  of 
an  end-product.  From  that  goal  other  utility  type  of  goals  can  be  derived,  which 
can  also  be  further  broken  down  into  validity  goals,  related  to  the  Modeling 
abstractions,  and  correctness  goals,  related  to  the  implementation  of  needed 
Conceptual  Model  views.  Some  of  the  utility  and  correctness  criteria  are  covered 
by  ISO/IEC  9126,  others  must  be  found  elsewhere  such  as  in  [Lindland],  [Pace]  or 
[Teeuw]  The  validity  criteria  will  be  highly  domain  and  application  dependent  and 
must  thus  be  derived  for  each  Conceptual  Model  anew  until  domain/application 
specific  referents  are  constructed.  After  the  criteria  have  been  defined  test  must  be 
defined  and  comparison  material  made  available  in  order  to  produce  evidence. 

The  tests  are  for  conceptual  models  often  executed  in  the  form  of  literature 
comparisons,  comparisons  with  existing  data  on  the  same  domain  or  problem  and 
often  it  will  be  the  collection  of  expert  opinion.  After  collection  of  evidence  it  is 
“summed  up”  as  a  V&V  Claim  Network  to  the  level  of  the  top  goal.  If  the  top 
claim  is  equal  to  the  top  goal,  fitness  for  purpose  of  the  Conceptual  Model  is 
shown.  If  this  is  not  the  case  the  culprit(s)  can  be  found  by  tracing  back  from  the 
top  claim  via  the  claim  hierarchy  to  evidence  that  indicate  failed  criteria  and  up  the 
goal  hierarchy  to  find  for  which  purposes  the  Conceptual  Model  can  not  be  proven 
to  be  good. 

Community 
of  Usage: 

Modeling  &  Simulation. 

Significant 

Attributes: 

Systematic  guidance  for  V&V. 
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ATTRIBUTE 

COMMENTS 

Below  mappings  are  provide  between  the  GM-V&V  and  the  guidance  in  this 
report. 

Mapping  of  Conceptual  Model  processes/products/roles  to  GM-V&V  is  shown  in 
the  tables  below. 

Mapping  of  Roles  Defined  in  this  Report  to  the  Roles  Defined  in  GM-V&V. 

NMSG-058 

GM-V&V 

Initiator/Sponsor/Client 

VV&A  Sponsor 

M&S  Project  Manager 

Custodian/ Administrator 

Controller/VV&A  Agent 

VV&A  Project  Manager,  Acceptance 

Leader,  V&V  Leader,  V&V  Implementers 

Consumers  /  Conceptual  Model 

Users 

W&A  Problem  Owner 

Mapping  between  GM-V&V  Processes  Steps  and  the  Process  Activities  Described 
in  this  Report. 

NMSG-058 

GM-V&V 

Relevance  to 

PP1  -  Initiate  Conceptual  Model 
Development 

VV&A  Requirements  Definition  Process 
VV&A  Requirements  Analysis  Process 

Our  Work: 

PP2  -  Define  Requirements  and 
Analyze  Knowledge  Needs  for  the 
Conceptual  Model 

Partial: 

V&V  Design  Process 

V&V  Implementation  Process 

V&V  Integration  Process 

PP3  -  Acquire  Mission  Space  and 
Simulation  Space  Knowledge 

Partial: 

V&V  Design  Process 

V&V  Implementation  Process 

V&V  Integration  Process 

PP4  -  Design  the  Conceptual 

Model 

Partial: 

V&V  Design  Process 

V&V  Implementation  Process 

V&V  Integration  Process 

PP5  -  Build  the  Conceptual  Model 

Final: 

V&V  Design  Process 

V&V  Implementation  Process 

V&V  Integration  Process 

Acceptance  Assessment  Process 

VV&A  Transition  Process 
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ATTRIBUTE 

COMMENTS 

Relevance  to  Our 
Work  (cont’d): 

Mapping  of  GM-V&V  “Worlds”  to  NMSG-058  “Spaces”. 

NMSG-058  GM-V&V 

Mission  space  Real  world 

Mission  space  Problem  world 

Simulation  space  M&S  world 

User  space  Product  world 

Relevance  of  Form 
for  Our  Product 
Specification 

N/A  pending  completion  of  SISO  product  standard. 

References: 

http://www.sisostds.org/StandardsActivities/DevelopmentGroups/GMVVPDGGen 

ericMethodologyforVVAintheM.aspx. 

Table  F-9:  Integration  Definition  for  Function  Modeling  (IDEF0). 


ATTRIBUTE 

COMMENTS 

Organization: 

NIST  -  National  Institute  of  Standards  and  Technology.  In  December  1993, 
the  Computer  Systems  Laboratory  of  the  National  Institute  of  Standards  and 
Technology  (NIST)  released  IDEF0  as  a  standard  for  Function  Modeling  in  FIPS 
Publication  183. 

Definition: 

Process  oriented  function  in  cell  (node),  controls/inputs/outputs  and  mechanisms- 
on-arrow  notation. 

Intended  Use: 

IDEF0  models  are  often  created  as  one  of  the  first  tasks  of  a  system  development 
effort.  IDEF0  is  useful  in  establishing  the  scope  of  an  analysis,  especially  for  a 
functional  analysis.  As  a  communication  tool,  IDEF0  enhances  domain  expert 
involvement  and  consensus  decision-making  through  simplified  graphical  devices. 
As  an  analysis  tool,  IDEF0  assists  the  modeler  in  identifying  what  functions  are 
performed,  what  is  needed  to  perform  those  functions,  what  the  current  system 
does  right,  and  what  the  current  system  does  wrong. 

Community 
of  Usage: 

Systems  engineers  needing  function  or  process-oriented  representational  notation. 

Significant 

Attributes: 

IDEF0  is  a  method  designed  to  model  the  decisions,  actions,  and  activities  of  an 
organization  or  system.  Effective  IDEF0  models  help  to  organize  the  analysis  of 
a  system  and  to  promote  good  communication  between  the  analyst  and  the 
customer.  Thus,  The  “box  and  arrow”  graphics  of  an  IDEF0  diagram  show  the 
function  as  a  box  and  the  interfaces  to  or  from  the  function  as  arrows  entering  or 
leaving  the  box. 
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COMMENTS 

Significant 

Attributes 

(cont’d): 

To  express  functions,  boxes  operate  simultaneously  with  other  boxes,  with  the 
interface  arrows  “constraining”  when  and  how  operations  are  triggered  and 
controlled.  The  basic  syntax  for  an  IDEF0  model  is  shown  in  the  figure  below. 

Controls 

▼  V 

Inputs 

Manufacturing  ** 

►  Function  - ► 

Outputs 

A  A 

Mechanisms 

Figure  F-1:  IDEF0  Box  and  Arrow  Graphics. 

Relevance  to 
Our  Work: 

The  fundamentals  of  function-on-node  and  control-on-arrow  notation  were  widely 
and  conveniently  used  by  the  Group  in  establishing  and  explaining  the  conceptual 
modeling  process. 

Relevance  of  Form 
for  Our  Product 
Specification: 

While  the  semantics  conveniently  captured  in  the  IDEF0  notation  schema  were 
carefully  considered  in  establishing  the  resulting  formal  specification  of  best- 
practice  process  contained  in  Annex  G;  nevertheless,  neither  IDEF0  notation  nor 
tools  were  used  to  produce  that  guidance  in  order  not  to  intimate  to  practitioners 
that  the  notation  per  se  was  either  required  or  preferentially  recommended. 

References: 

http://www.idef.com/IDEFO.htm;  http://www.idef.com/pdf/idefO.pdf. 

Table  F-10:  Integration  Definition  for  Function  Modeling  (IDEF5). 


ATTRIBUTE 

COMMENTS 

Organization: 

Armstrong  Faboratory,  AF/HRGA,  Wright-Patterson  Air  Force  Base,  Ohio  45433 

Definition: 

Ontology  Description  Capture  Method. 

Intended  Use: 

The  IDEF5  method  provides  a  theoretically  and  empirically  well-grounded  method 
specifically  designed  to  assist  in  creating,  modifying,  and  maintaining  ontologies. 
Standardized  procedures,  the  ability  to  represent  ontology  information  in  an 
intuitive  and  natural  form,  and  higher  quality  results  enabled  through  IDEF5 
application  also  serve  to  reduce  the  cost  of  these  activities. 
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ATTRIBUTE 

COMMENTS 

Community 
of  Usage: 

Systems  engineers  /  Ontology  analysts. 

Significant 

Attributes: 

Supporting  the  ontology  development  process  are  IDEF5’s  ontology  languages. 
There  are  two  such  languages:  the  IDEF5  schematic  language  and  the  IDEF5 
elaboration  language.  The  schematic  language  is  a  graphical  language,  specifically 
tailored  to  enable  domain  experts  to  express  the  most  common  forms  of 
ontological  information.  The  other  language  is  the  IDEF5  elaboration  language, 
a  structured  textual  language  that  allows  detailed  characterization  of  the  elements 
in  the  ontology. 

Relevance  to 
Our  Work: 

IDEF5  focuses  particularly  on  Ontology  languages.  On  that  account  it  is  neither  as 
intuitive  nor  as  powerful  as  UML  or  other  such  notations  in  addressing  the 
generation  of  ontological  descriptions  per  se,  nor  in  documenting  them  for 
persistent  reference  as  is  necessary  in  simulation  conceptual  modeling.  This  bias 
and  relative  dislocation  from  the  purpose  of  the  Task  Group’s  scope  of  interest  is 
reflected  in  both  the  IDEF  concepts  and  in  its  diagrammatic  -notational 
vocabulary.  The  standard  was  not  strongly  or  formally  employed  in  the  Task 
Group’s  effort,  though  it  might  have  served  well  enough  for  the  subject 
deliberations  if  its  familiarity  were  more  prevalent  among  team  members. 

Relevance  of  Form 
for  Our  Product 
Specification: 

The  standard  was  not  invoked  explicitly  in  formulation  of  an  expression  of  the 
best-practice  guidance  despite  its  ontological  intentions.  Whether  its  use  in 
execution  of  the  best-practice  proffered,  is  left  as  with  all  other  standards  to  the 
discretion  of  the  practitioner  in  context  of  the  prevailing  conceptual  modeling 
enterprise  environment. 

References: 

http://www.idef.com/IDEF5.htm;  http://www.idef.com/pdf/Idef5.pdf. 

Table  F-11:  Joint  Command  Control  Communication  Information  Exchange  Data  Model  (JC3IDEM). 


ATTRIBUTE 

COMMENTS 

Organization: 

The  NATO  Data  Administration  Group  (NDAG)  cooperates  with  the  (Multi¬ 
national  Interoperability  Programme)  MIP’s  Data  Modeling  Working  Group 
(DMWG)  in  building  of  JC3IEDM. 

Definition: 

JC3IEDM,  or  Joint  Command,  Control  and  Consultation  Information  Exchange 

Data  Model  is  an  evolution  of  the  Command  and  Control  Information  Exchange 
Data  Model  (C2IEDM)  standard  that  includes  joint  operational  concepts,  just  as 
the  Land  Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM) 
was  extended  to  become  C2IEDM. 

Intended  Use: 

The  overall  goal  is  to  specify  the  minimum  set  of  data  that  needs  to  be  exchanged 
in  coalition  or  multi-national  operations. 
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COMMENTS 

Intended  Use 
(cont’d): 

Each  NATO  Nation,  agency  or  community  of  interest  is  free  to  expand  its  own 
data  dictionary  to  accommodate  its  additional  information  exchange  requirements 
with  the  understanding  that  the  added  specifications  will  be  valid  only  for  the 
participating  NATO  Nation,  agency  or  community  of  interest.  Any  addition  that  is 
deemed  to  be  of  general  interest  may  be  submitted  as  a  change  proposal  within  the 
configuration  control  process  to  be  considered  for  inclusion  in  the  next  version  of 
the  specification.  The  main  source  of  information  and  the  basis  for  the  ontology 
design  and  development  is  the  MIP  (Multi-lateral  Interoperability  Programme) 
proposed  standard  JC3IEDM.  The  MIP  aims  to  provide  an  assured  capability  for 
interoperability  of  information  to  support  joint  military  operations.  Interoperability 
is  not  envisioned  merely  at  a  data  level  but  also  at  strategic,  operational  and 
tactical  level  to  allow  proper  planning  and  functioning  of  joint  operations. 

Community 
of  Usage: 

NATO  North  Atlantic  Treaty  Organisation. 

Significant 

Attributes: 

JC3IEDM  is  intended  to  represent  the  core  of  the  data  identified  for  exchange 
across  multiple  functional  areas  and  multiple  views  of  the  requirements.  Toward 
that  end,  it  lays  down  a  common  approach  to  describing  the  information  to  be 
exchanged  in  a  Command  and  Control  (C2)  environment. 

•  The  structure  should  be  sufficiently  generic  to  accommodate  joint,  land,  sea, 
and  air  environmental  concerns. 

•  The  data  model  describes  all  objects  of  interest  in  the  sphere  of  operations, 
e.g.,  organizations,  persons,  equipment,  facilities,  geographic  features,  weather 
phenomena,  and  military  control  measures  such  as  boundaries. 

•  Objects  of  interest  may  be  generic  in  terms  of  a  class  or  a  type  and  specific 
in  terms  of  an  individually  identified  item.  All  object  items  must  be  classified 
as  being  of  some  type  (e.g.,  a  specific  tank  that  is  identified  by  serial  number 
WS62105B  is  an  item  of  type  “Challenger”  that  is  a  heavy  UK  main  battle 
tank). 

•  An  object  must  have  the  capability  to  perform  a  function  or  to  achieve  an  end. 
Thus,  a  description  of  capability  is  needed  to  give  meaning  to  the  value  of 
objects  in  the  sphere  of  operations. 

•  It  should  be  possible  to  assign  a  location  to  any  item  in  the  sphere  of 
operations.  In  addition,  various  geometric  shapes  need  to  be  represented  in 
order  to  allow  commanders  to  plan,  direct,  and  monitor  operations.  Examples 
include  boundaries,  corridors,  restricted  areas,  minefields,  and  any  other 
control  measures  needed  by  commanders  and  their  staffs. 

•  Several  aspects  of  status  of  items  need  to  be  maintained. 

•  The  model  must  permit  a  description  of  the  composition  of  a  type  object  in 
terms  of  other  type  objects.  Such  concepts  include  tables  of  organizations, 
equipment,  or  personnel. 

•  The  model  must  reflect  information  about  what  is  held,  owned  or  possessed  in 
terms  of  types  by  a  specific  object  item. 
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COMMENTS 

Significant 

Attributes 

(cont’d): 

•  There  is  a  need  to  record  relationships  between  pairs  of  items.  Key  among 
these  is  the  specification  of  unit  task  organizations  and  orders  of  battle. 

•  The  model  must  support  the  specification  of  current,  past,  and  future  role  of 
objects  as  part  of  plans,  orders,  and  events. 

•  The  same  data  structure  should  be  used  to  record  information  for  all  objects, 
regardless  of  their  hostility  status. 

•  Provision  must  be  made  for  the  identification  of  sources  of  information, 
the  effective  and  reporting  times,  and  an  indication  of  the  validity  of  the  data. 

The  JC3IEDM  is  described  from  three  different  perspectives: 

•  Conceptual  Data  Model:  A  top,  high  level,  Conceptual  Data  Model  of 
generalized  concepts  such  as  Actions,  Organizations,  Materiel,  Personnel, 
Features,  Facilities,  Focations,  intended  for  top  officers,  senior  commanders, 
etc.,  who  do  not  need  to  know  the  specific  technical  details  of  the  model,  but  is 
sufficient  to  be  aware  of  the  different  concepts  and  their  relationships. 

•  Fogical  Data  Model:  Middle,  Fogical  Data  Model  which  is  more  detailed, 

is  based  upon  breaking  down  the  high  level  concepts  into  specific  information 
that  is  regularly  used.  For  example,  a  tank  is  an  armored  fighting  vehicle  that  is 
a  piece  of  equipment  that  is  a  piece  of  materiel.  It  also  makes  implicit 
knowledge  explicit,  like  following  the  human  reasoning  patterns  that  a  tank  is  a 
piece  of  armored  fighting  equipment  and  allows  command  and  control  systems 
to  generalize  by  recognizing,  for  instance,  that  tanks  are  equipment.  A  logical 
data  model  specifies  the  way  data  is  structured  with  an  entity-attribute- 
relationship  diagram  and  supporting  documentation.  At  this  level,  technical 
implementation  specific  details  are  still  obscured  from  view.  This  level  is 
useful  for  middle  level  system  analysts  and  domain  experts. 

•  Physical  Data  Model:  The  third  and  lower  most,  Physical  Data  Model  provides 
the  detailed  specifications  that  are  necessary  to  generate  a  physical  schema  that 
defines  the  structure  of  a  database.  Mainly  intended  for  the  information  system 
developer.  The  physical  data  model  can  be  seen  as  a  traditional  database 
schema  model,  which  illustrates  the  different  logical  concepts  (tables),  their 
attributes  (fields)  and  the  relationships. 

Relevance  to 
Our  Work: 

•  To  describe  a  Conceptual  Model,  one  needs  the  same  concepts  of  Objects  or 
Entities  of  interests  around  which  the  operation  is  focused. 

•  Each  entity  has  both  static  characteristics  as  well  as  dynamic  properties,  as  is 
represented  by  the  situation  concepts  in  the  JC3IEDM. 

•  Relevant  if  the  main  focus  in  our  conceptual  models  is  that  of  activities,  or 
Actions  as  proposed  in  the  JC3IEDM  as  well. 

•  And  to  co  relate  pieces  of  information,  to  provide  the  context  and  other  vital 
information,  a  group  of  information  packages  is  required  as  well. 

Relevance  of  Form 
for  Our  Product 
Specification: 

It  depends  on  our  chosen  Conceptual  models  structure,  content  or  process  will 
make  use  of. 
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References: 

http://www.mip-site.org. 

http://encyclopedia.thefreedictionary.com/JC3IEDM. 

http://en.wikipedia.org/wiki/JC3IEDM. 

FOI-R — 175— SE. 

Table  F-12:  Kernel  Meta  Meta  Model  (KM3). 

ATTRIBUTE 

COMMENTS 

Organization: 

FOI  -  Swedish  Defence  Research  Agency 

Definition: 

The  Knowledge  Meta  Model  (KM3),  developed  by  the  Swedish  Defence  Research 
Institute  (FOI),  has  its  place  as  a  tool  and  a  language  to  construct  well-formed 
conceptual  models  that  are  to  be  used  successfully  in  simulation  model  and 
Development. 

Intended  Use: 

The  intention  when  producing  the  KM3  was  not  to  construct  a  grand  “unified 
model  description  language”.  It  rather  represents  one  possibility  to  capture  system 
structures  and  behavior  in  an  object-oriented  and  rule-based  way.  The  KM3  is  all 
of  the  following  (in  no  particular  order): 

•  The  KM3  is  a  specification.  It  is  a  specification  consisting  of  object-oriented 
concepts,  primarily  aimed  at  capturing  different  dependencies  in  and  between 
activities.  In  this  setting  this  means  that  the  KM3  is  a  specification  for  the 
creation  of  generic  and  reusable  conceptual  models  of  objects  and  processes 
of  (military)  interest. 

•  The  KM3  is  a  tool.  It  is  a  tool  for  structuring  knowledge  about  objects  and 
processes  as  conceptual  models.  The  main  objective  of  KM3  is  to  produce 
generic  templates  of  knowledge  (MSMs,  in  the  above  list). 

•  The  KM3  is  a  language.  It  is  a  common  language  to  for  different  stakeholders 
involved  in  the  modeling  process,  to  enable  them  to  construct  conceptual 
models. 

The  KM3  is  mainly  used  as  a  specification  for  construction  of  generic  models, 
which  in  turn  are  used  to  model  knowledge  at  an  instance  level.  KM3  is,  in  this 
respect,  a  model  for  how  to  make  models.  A  model  produced  using  the  KM3  is  a 
well-formed,  well-understood  conceptual  model  which  in  turn  can  be  instantiated 
to  be  used  as  a  simulation  model. 

Community 
of  Usage: 

FOI  and  Swedish  Armed  Forces. 

Significant 

Attributes: 

•  Is  an  activity  centric  structure. 

•  Covers  static  and  dynamic  aspects  of  objects  in  the  same  model. 

•  Covers  relations  between  objects. 

•  Captures  rules  of  behaviour. 
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COMMENTS 

Relevance  to 
Our  Work: 

•  A  general  and  flexible  structure  and  a  potential  candidate  for  Conceptual  Model 
Template. 

•  The  interpreted  information  is  subsequently  transformed  into  a  common  format, 
generalized  and  stored  as  a  reusable  model.  This  common  format  is  described  by 
a  Knowledge  Meta  Model  (KM3). 

•  The  reusable  conceptual  model,  now  called  a  Mission  Space  Model  (MSM),  can  be 
instantiated  with  real-world  data  and  serve  as  a  basic  structure  when  performing 
simulations. 

Relevance  of  Form 
for  Our  Product 
Specification: 

A  source  of  inspiration  and  example  of  the  way  we  can  specify  our  Conceptual 
Models. 

References: 

FOI-R—  1754-SE. 

05F-SIW-040. 

Table  F-13:  Model  Driven  Architecture  (MDA). 

ATTRIBUTE 

COMMENTS 

Organization: 

Object  Management  Group  (OMG) 

Definition: 

Model  Driven  Architecture  (MDA)  is  a  software  development  process  (Ml  level, 
because  it  specifies  the  Modeling  languages).  It  is  the  base  architecture  for  OMG’s 
software  development  standards,  including  MOF,  UML,  OWM  and  XMI. 

Intended  Usage: 

MDA  separates  software  business  and  application  logic  from  underlying  platform 
technology.  By  leveraging  OMG’s  universally  accepted  MOF  and  UML  standards, 
the  MDA  allows  creation  of  software  applications  that  are  portable  across,  and 
interoperate  naturally  across,  a  broad  spectrum  of  systems  from  embedded, 
to  desktop,  to  server,  to  mainframe,  and  across  the  Internet.  In  MDA,  attention 
focuses  first  on  the  application’s  business  functionality  and  behavior,  allowing 
stakeholders’  investment  to  concentrate  on  the  aspects  that  critically  affect  core 
business  processes.  Technical  aspects,  also  critical  but  secondary  to  business 
functions,  are  well  handled  by  automated  or  semi-automated  development  tools. 
MDA  is  always  ready  to  deal  with  yesterday’s,  today’s  and  tomorrow’s  challenges 
and  makes  it  easier  to  integrate  applications  and  facilities  across  middleware 
boundaries.  Domain  facilities  defined  in  the  MDA  by  OMG’s  Domain  Task  Forces 
provide  much  wider  interoperability  by  always  being  available  on  a  domain’s 
preferred  platform,  and  on  multiple  platforms  whenever  there  is  a  need. 

Community 
of  Usage: 

OMG  Task  Forces  organized  around  industries  including  Finance,  Manufacturing, 
Biotechnology,  Space  technology,  and  others  use  the  MDA  to  standardize  facilities 
in  their  domains. 
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Significant 

Attributes: 

The  MDA  is  structured  around  Computation  Independent  Model  (CIM),  Platform 
Independent  Model  (PIM),  Platform  Specific  Model  (PSM)  and  implementations: 

•  The  CIM  represents  the  requirements  of  the  system  in  the  form  of  a 
domain  model.  It  is  also  a  source  of  vocabulary  for  the  other  models. 

The  transformations  from  and  to  this  model  are  mainly  for  requirements 
traceability. 

•  The  PIM  describes  a  system  without  anchoring  it  to  technology-specific 
functional  interfaces. 

•  The  PSM  implements  in  an  abstract  fashion  the  specification  of  the  PIM  using 
technology-specific  functionalities. 

•  The  Implementation  is  the  operational  system. 

The  different  models  are  linked  through  automatic  conversions.  This  improves 
traceability,  consistency,  uniformity  and  productivity.  The  MDA  is  implemented 
using  OMG’s  software  development  standards.  The  MOF  is  OMG’s  foundation 
specification  for  modeling  languages;  MOF  compliance  allows  UML  structural 
and  behavioral  models,  and  CWM  data  models,  to  be  transmitted  via  XMI,  stored 
in  MOF-compliant  repositories,  and  transformed  and  manipulated  by  MOF- 
compliant  tools  and  code  generators.  Patterns  play  a  critical  role  in  most  MDA- 
based  development  projects.  Successful  transformation  from  PIM  to  PSM, 
and  from  PSM  to  code,  requires  that  the  PIM  contain  enough  detail  to  completely 
guide  the  software  tools  through  the  process.  By  incorporating  this  detail  through 
the  use  of  patterns,  instead  of  inserting  it  by  hand,  we  gain  multiple  benefits: 
architects  do  less  work,  the  resulting  PIM  reflects  the  collective  wisdom  of  many 
contributors,  and  the  tools  can  work  the  pattern  (parameterized  as  necessary  in  our 
UML  models)  through  the  transformations,  ultimately  pulling  implementation  code 
from  a  library  written  by  experts  and  inserting  it  into  the  application. 

Relevance  to 
Our  Work: 

The  MDA  process  could  be  applied  directly  to  M&S  conceptual  modeling, 
i.e.,  that  a  new  MOF-based  conceptual  model  language  adapted  to  military  M&S 
could  be  developed  or  an  existing  one  could  be  reused  (e.g.,  UML).  However, 
since  the  MSG-058  mandate  is  to  provide  a  guidance  (M2  level),  proposing  the 
MDA  as-is  would  be  too  prescriptive.  MDA  could  be  stated  as  an  example  of  a 
development  process  implementation  leading  to  a  high  level  of  maturity:  focus  on 
functionality  and  behavior  while  technical  aspects  are  automated  or  semi- 
automated,  high  maintainability  and  interoperability  through  shared  domain 
facilities.  The  notion  of  patterns  is  also  desirable  to  apply  in  the  MSG-058  work- 
product. 

Relevance  of  Form 
for  Our  Product 
Specification: 

The  MDA  philosophy  (different  abstraction  levels  linked  with  automatic 
transformations)  is  applicable  to  the  MSG-058  product  specification.  It  has 
influenced  our  strategic  goal  because  it  greatly  improves  the  level  of  maturity  of  a 
process. 

References: 

MDA  -  http://www.omg.org/mda/. 

MDA  Guide  Version  1.0.1,  OMG,  omg/2003-06-01,  June  2003,  62  pp. 
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References 

(cont’d): 

MOF  -  http://www.omg.org/mof/. 

Meta  Object  Facility  (MOF)  Specification  Version  1.4,  OMG,  April  2002,  358  pp. 
UML  -  http://www.uml.org/. 

Unified  Modeling  Language  Specification  Version  1.4.2,  OMG  formal/05-04-01, 
ISO/IEC  19501:2005(E),  January  2005,  454  pp. 

OMG  Unified  Modeling  Language  (UML),  Infrastructure,  V2.1.2,  formal/2007- 
11-04,  November  2007,  224  pp. 

OMG  Unified  Modeling  Language  (OMG  UML),  Superstructure,  V2.1.2, 
formal/2007-1 1-02,  November  2007,  738  pp. 

Table  F-14:  NATO  Architecture  Framework  (NAF). 


ATTRIBUTE 

COMMENTS 

Organization: 

NATO,  NC3A 

Definition: 

NATO  Architecture  Framework  is  a  derivative  framework  based  on  DoDAF. 

Intended  Use: 

•  It  provides  guidance  on  describing  communication  and  information  systems 
(or  C3  systems)  through  architectures  and  provides  the  rules,  guidance,  and 
templates  for  developing  and  presenting  architecture  descriptions  to  ensure  a 
common  denominator  for  understanding,  comparing,  and  integrating 
architectures  in  NATO.  The  application  of  the  NAF  is  designed  to  enable 
architectures  to  contribute  most  effectively  to  acquiring  and  fielding  cost- 
effective  and  interoperable  military  capabilities. 

•  The  ability  to  define  views  of  architectural  information  in  a  more  flexible  way 
and  support  Stakeholders  so  that  extensive  analysis  can  be  made  to  provide 
rationale  for  prioritization  decision-making. 

•  A  standardized  way  of  documenting  NATO-wide  business  processes  and  to 
provide  support  to  Capability -based  planning. 

•  Critical  support  for  the  achievement  of  NNEC  and  NATO  transformation  by 
facilitating  the  move  from  a  system-oriented  paradigm  to  a  service-oriented 
paradigm,  and  by  identifying  mechanisms  to  handle  the  complexity  of  the 
relationships  within  the  NATO  federation  of  systems  in  a  holistic  manner. 

•  A  NAF  Meta-Model  (NMM)  and  repository  to  enable  stakeholders  and  users  to 
extract  bespoke  architecture  information  and  make  necessary  analyses  to  support 
development,  interoperability,  acquisition  or  technical  considerations. 

•  A  complementary  tool  to  NATO  and  National  programme  management, 
contributing  to  reduction  in  cost  overruns,  risk  reduction,  and  more  efficient  use 
of  common  funded  budgets. 
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COMMENTS 

Intended  Use 
(cont’d): 

•  A  coherent  mechanism  to  identify  capability  gaps  and  promote  interoperability 
across  NATO,  including  for  the  critical  deployed  force  and  NRF  scenarios. 

Community 
of  Usage: 

NATO,  PfP. 

Significant 

Attributes: 

The  NAF  is  still  in  development. 

NAF  introduces  a  number  of  new  “Service  Views”  to  support  Service  Orientated 
Architecture. 

It  is  likely  that  DoDAF  and  NAF  may  converge  into  a  single  or  very  closely 
related  architecture  sometime  in  the  near  future. 

Relevance  to 
Our  Work: 

See  DoDAF. 

Relevance  of  Form 
for  Our  Product 
Specification 

See  DoDAF. 

References: 

http :// 1 94.7.80. 1 53/website/book.asp?menuid=l  5&vs=0&page=volumel%2Fch03 
s02.html. 

Table  F-15:  Open  Knowledge  Base  Connectivity  (OKBC). 

ATTRIBUTE 

COMMENTS 

Organization: 

The  development  of  OKBC  is  being  overseen  by  a  working  group.  Richard  Fikes 
is  the  working  group  chair  and  the  following  six  institutions  are  the  voting 
members: 

•  Cycorp; 

•  Information  Sciences  Institute; 

•  Knowledge  Systems  Laboratory,  Stanford; 

•  Science  Applications  International  Corporation  (SAIC); 

•  SRI  International;  and 

•  Teknowledge. 

Definition: 

OKBC  is  an  application  programming  interface  for  accessing  knowledge  bases 
stored  in  Knowledge  Representation  Systems  (KRSs).  OKBC  is  being  developed 
under  the  sponsorship  of  DARPA’s  High  Performance  Knowledge  Base  program 
(HPKB),  where  it  is  being  used  as  an  initial  protocol  for  the  integration  of  various 
technology  components. 
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COMMENTS 

Intended  Use: 

[OKBC]  . . .  provides  a  set  of  operations  for  a  generic  interface  to  underlying  KRSs 
...  OKBC  is  complementary  to  language  specifications  developed  to  support 
knowledge  sharing.  KIF,  the  Knowledge  Interchange  Format,  provides  a 
declarative  language  for  describing  knowledge.  As  a  pure  specification  language, 
KIF  does  not  include  commands  for  knowledge  base  query  or  manipulation. 
Furthermore,  KIF  is  far  more  expressive  than  most  KRSs.  OKBC  focuses  on 
operations  that  are  efficiently  supported  by  most  KRSs  (e.g.,  operations  on  frames, 
slots,  facets  —  inheritance  and  slot  constraint  checking).  OKBC  is  intended  to  be 
well  impedance-matched  to  the  sorts  of  operations  typically  performed  by 
applications  that  view  or  manipulate  object-oriented  KRSs. 

Community 
of  Usage: 

Knowledge  management  specialists. 

Significant 

Attributes: 

OKBC  specifies  a  knowledge  model  of  KRSs  (with  KBs,  classes,  individuals, 
slots,  and  facets).  It  also  specifies  a  set  of  operations  based  on  this  model 
(e.g.,  find  a  frame  matching  a  name,  enumerate  the  slots  of  a  frame,  delete  a 
frame).  An  application  uses  these  operations  to  access  and  modify  knowledge 
stored  in  an  OKBC-compliant  KRS. 

Significant 

Attributes: 

The  current  implementation  of  OKBC  is  object-oriented:  methods  in  the 
appropriate  object-oriented  programming  language  for  an  application  are  used  to 
implement  OKBC  operations.  We  refer  to  the  set  of  methods  that  implement  the 
protocol  for  a  particular  KRS  as  a  back  end.  Many  OKBC  operations  have  default 
implementations  written  in  terms  of  other  OKBC  operations;  therefore,  the 
programmer  need  define  only  a  core  sub-set  of  all  OKBC  operations  in  order  to 
implement  a  compliant  back  end.  These  OKBC  operations  are  called  mandatory, 
and  they  comprise  the  OKBC  kernel.  The  default  implementations  can  be 
overridden  within  a  given  back  end  to  improve  efficiency.  The  design  objectives 
for  OKBC  are  as  follows.  Simplicity:  It  is  important  to  have  a  relatively  simple 
specification  that  can  be  implemented  quickly,  even  if  that  means  sacrificing 
theoretical  considerations  or  support  for  idiosyncrasies  of  a  particular  KRS. 
Generality:  The  protocol  should  apply  to  many  KRSs,  and  support  all  the  most 
common  KRS  features.  For  example,  it  should  support  all  the  knowledge  access 
and  modification  functionality  that  will  be  required  by  a  graphical  KB  editor. 

The  protocol  should  not  require  numerous  changes  to  a  KRS  for  which  the 
protocol  is  implemented.  That  is,  the  protocol  should  not  legislate  the  behavior  of 
an  underlying  KRS,  but  should  serve  as  an  interface  between  an  existing  KRS  and 
an  application.  Performance:  Inserting  the  protocol  between  an  application  and  a 
KRS  should  not  introduce  a  significant  performance  cost.  Consistency: 

The  protocol  should  exhibit  consistent  behavior  across  different  KRSs.  That  is, 
a  given  sequence  of  operations  within  the  protocol  should  yield  semantically 
equivalent  results  over  a  range  of  KRSs. 

Relevance  to 
Our  Work: 

OKBC  is  of  potential  use  in  executing  any  of  the  various  knowledge  collection  and 
management  activities  cited  within  the  best-practice  process. 
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ATTRIBUTE 

COMMENTS 

Relevance  of  Form 
for  Our  Product 
Specification: 

While  OKBC  was  not  used  explicitly  in  the  best-practice  process  specification,  it  is 
understood  that  utility  may  be  found  by  the  practitioner  in  executing  the  best- 
practice  process  and  in  documenting  the  conceptual  model  product  itself. 

References: 

http://www.ai.sri.com/-okbc/. 

http://www.ai.sri.com/-okbc/spec.html. 

Table  F-16:  Web  Ontology  Language  (OWL). 

ATTRIBUTE 

COMMENTS 

Organization: 

W3C  -  Worldwide  Web  Consortium 

Definition: 

“OWL  is  the  W3C’ s  recommended  ontology  Language  for  representing 
information  on  the  Semantic  Web.  It  is  typically  used  to  define  an  ontology  for  a 
particular  domain.  An  OWL  ontology  is  a  set  of  axioms  describing  classes, 
properties,  and  the  relationships  between  them.”  -  Lacey  2005. 

Intended  Use: 

“The  purpose  of  OWL  is  to  provide  a  standard  language  for  Semantic  Web 
information  representation.”  -  Lacey.  The  W3C  OWL  2  Web  Ontology  Language 
(OWL)  is  a  Semantic  Web  language  designed  to  represent  rich  and  complex 
knowledge  about  things,  groups  of  things,  and  relations  between  things.”  OWL  is 
a  computational  logic-based  language  such  that  knowledge  expressed  in  OWL  can 
be  reasoned  with  by  computer  programs  either  to  verify  the  consistency  of  that 
knowledge  or  to  make  implicit  knowledge  explicit.  OWL  documents,  known  as 
ontologies,  can  be  published  in  the  World  Wide  Web  and  may  refer  to  or  be 
referred  from  other  OWL  ontologies”  -  http://www.w3.org/TR/2009/REC-owl2- 
primer-2009 1 027/. 

Community 
of  Usage: 

Data  managers,  web  application  developers,  and  database  engineers  who  what  to 
leverage  the  power  of  the  Semantic  Web  by  representing  their  information  using 
the  Web  Ontology  Language  -  OWL  in  order  to  enable  Semantic  Web  applications 
and  services  to  process  and  interpret  content. 

Significant 

Attributes: 

“OWL  2  is  a  language  for  expressing  ontologies.”  “OWL  2  is  not  a  programming 
language:  OWL  2  is  declarative,  i.e.,  it  describes  a  state  of  affairs  in  a  logical  way” 
“OWL  2  is  not  a  schema  language  for  syntax  conformance.”  “OWL  2  is  not  a 
database  framework.”  “OWL  2  is  a  knowledge  representation  language,  designed 
to  formulate,  exchange  and  reason  with  knowledge  about  a  domain  of  interest”. 
OWL  assumes  basic  knowledge  modeling  practice  and  includes  provision  for 
representation  of  information  related  to  classes,  properties,  and  individuals. 

For  survey  of  features  see:  http://www.w3.org/TR/2009/REC-owl2-primer- 
20091027/#ref-owl-2-quick-reference.  The  currently  most  widely  used  OWL 
editor  is  Protege,  a  free  open-source  editing  framework  developed  at  Stanford 
University. 
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ATTRIBUTE 

COMMENTS 

Significant 

Attributes 

(cont’d): 

By  virtue  of  its  open  plug-in  structure,  it  allows  for  the  easy  integration  of  special- 
purpose  ontology  editing  components.  Other  editors  include  TopQuadrant’s 
commercial  TopBraid  Composer  and  the  open-source  systems  SWOOP  and  NeOn- 
Toolkit.  There  are  several  reasons  for  OWL  DL  which  differs  somewhat  in  terms 
of  coverage  of  the  supported  reasoning  features.  For  some  of  these,  OWL  2 
conformance  is  currently  planned  and  the  corresponding  implementations  are  in 
progress.  The  Test  Suite  Status  document  lists  to  which  extent  some  of  the  reasons 
mentioned  below  comply  with  the  test  cases.  For  reasoning  within  OWL  DL, 
the  most  prominent  systems  are  Fact++  by  the  University  of  Manchester,  Hermit 
by  Oxford  University  Computing  Laboratory,  Pellet  by  Clark  &  Parsia,  LLC, 
and  RacerPro  by  Racer  Systems.  In  addition  to  those  general-purpose  reasons 
aiming  at  supporting  all  of  OWL  DL,  there  are  reasoning  systems  tailored  to  the 
tractable  profiles  of  OWL.  CEL  by  Dresden  University  of  Technology  supports 
OWL  EL.  QuOnto  by  Sapienza  University  di  Roma  supports  OWL  QL.  ORACLE 

1 1  g  supports  OWL  RL.  The  open-source  OWL  API  plays  a  rather  prominent  role 
as  the  currently  most  important  development  tool  around  OWL. 

Relevance  to 
Our  Work: 

The  OWL  standard  and  knowledge/concept  specification  schema  is  designed  to 
address  the  description  of  ontological  domains.  In  the  present  work,  such  relevant 
domains  are  the  military  mission  space  and  simulation  executive  domains. 

Therefore  OWL  is  a  language  whose  relevance  to  expressing  the  semantic  content 
of  military  model  and  simulation  conceptual  models  is  direct  and  obvious.  Further, 
toe  prospect  of  using  Semantic  Web  interface  and  communications  infrastructure 
in  association  with  cloud  computing  techniques  is  highly  suggestive  for  the  present 
effort.  Relationship  of  OWL  to  XML  is  also  prospectively  significant  for 
consideration  of  machine  readable  military  model  and  simulation  conceptual 
models. 

Relevance  of  Form 
for  Our  Product 
Specification: 

The  notational  schema  manifest  in  OWL  for  ontology  specification  and  semantic 
elaboration  is  effectively  similar  to  that  of  UML  and  is  manifestly  suitable  to  the 
needs  for  notational  specification  of  military  simulation  conceptual  models. 

References: 

OWL:  Representing  Information  Using  the  Web  Ontology  Language,  Lee  W. 

Lacey,  Trafford,  Victoria,  BC,  Canada,  2005;  and  http://www.w3.Org/TR/#tr_ 

O  WL_W  ebOntologyLanguage . 

Table  F-17:  Resource  Description  Framework  (RDF). 

ATTRIBUTE 

COMMENTS 

Organization: 

World- Wide-Web  Consortium  (W3C) 

Definition: 

“RDF  is  a  standard  model  for  data  interchange  on  the  Web.  RDF  has  features  that 
facilitate  data  merging  even  if  the  underlying  schemas  differ,  and  it  specifically 
supports  the  evolution  of  schemas  over  time  without  requiring  all  the  data 
consumers  to  be  changed.” 
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ATTRIBUTE 

COMMENTS 

Intended  Use: 

Semantic  description  of  data  exchanged  between  independent  users.  It  is  not 
human  readable. 

Community 
of  Usage: 

Anyone  who  need  to  describe  web  content  such  that  independent  applications  can 
discover  and  retrieve  it. 

Significant 

Attributes: 

“RDF  extends  the  linking  structure  of  the  Web  to  use  URIs  to  name  the 
relationship  between  things  as  well  as  the  two  ends  of  the  link  (this  is  usually 
referred  to  as  a  “triple”).  Using  this  simple  model,  it  allows  structured  and  semi- 
structured  data  to  be  mixed,  exposed,  and  shared  across  different  applications. 

This  linking  structure  forms  a  directed,  labeled  graph,  where  the  edges  represent 
the  named  link  between  two  resources,  represented  by  the  graph  nodes.  This 
graph  view  is  the  easiest  possible  mental  model  for  RDF  and  is  often  used  in 
easy-to-understand  visual  explanations.”  RDF  is  written  in  XML.  It  is  designed  to 
be  read  by  computers.  Its  basic  building  block  is  an  object-attribute- value  triple, 
called  a  statement. 

Relevance  to 
Our  Work: 

May  be  used  for  representing  Meta  data  about  conceptual  models. 

Relevance  of  Form 
for  Our  Product 
Specification: 

The  Task  Group  did  not  use  RDF  standard  specifications  or  standards  in  framing 
the  best-practice  guidance  for  military  model  conceptual  modeling  on  the 
assumption  that  our  work-product  would  be  a  text  document  and  that  a  practitioner 
would  leverage  such  relatively  fundamental  standards  in  accordance  with  their 
own  enterprise  practices  in  due  course  of  developing  and  managing  simulation 
conceptual  models. 

References: 

http://www.w3  .org/RDF/. 

http://www.w3.org/standards/techs/rdf. 

http://www.w3.org/2001/sw/. 

Table  F-18:  Rational  Unified  Process  (RUP). 

ATTRIBUTE 

COMMENTS 

Organization: 

IBM 

Definition: 

“IBM  Rational  Unified  Process®  (RUP®)  is  a  comprehensive  process  framework 
that  provides  industry-tested  practices  for  software  and  systems  delivery  and 
implementation  and  for  effective  project  management.” 

Intended  Use: 

“RUP  promotes  iterative  development  and  organizes  the  development  of  software 
and  systems  into  four  phases,  each  consisting  of  one  or  more  executable  iterations 
of  the  software  at  that  stage  of  development.” 

Community 
of  Usage: 

Software  developers  in  enterprise  environments  and  project  teams. 

Significant 

Attributes: 

Systematic,  tailorable  process  for  software  development.  Extensive  support  tools 
and  training/coaching  available. 
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ATTRIBUTE 

COMMENTS 

Relevance  to 
Our  Work: 

Significant  software  development  bias  but  includes  software  system  conceptual 
modeling  within  scope. 

Relevance  of  Form 
for  Our  Product 
Specification 

N/A. 

References: 

http://www-0 1  .ibm.com/software/awdtools/rup/. 

http://www.ibm.com/developerworks/rational/library/content/03July/ 1 000/ 1251/12 
51  bestpractices_TP026B.pdf. 

“Rational  Unified  Process,  Best-Practices  for  Software  Development  Teams, 
Rational  Software  -  White  Paper”,  TP026B,  Rev  11/01. 

Table  F-19:  Systems  Modeling  Language  (SysML). 

ATTRIBUTE 

COMMENTS 

Organization: 

The  UML  for  Systems  Engineering  RFP  was  developed  jointly  by  the  OMG  and 
the  International  Council  On  Systems  Engineering  (INCOSE)  and  issued  by  the 
OMG  in  March  2003 

Definition: 

Systems  Modeling  Language. 

Intended  Use: 

The  SysML  is  a  Domain-Specific  Modeling  language  for  systems  engineering. 

It  supports  the  specification,  analysis,  design,  verification  and  validation  of  a  broad 
range  of  systems  and  systems-of-systems.  SysML  was  originally  developed  by  an 
open  source  specification  project,  and  includes  an  open  source  license  for 
distribution  and  use.  SysML  is  defined  as  an  extension  of  a  sub-set  of  the  Unified 
Modeling  Language  (UML)  using  UML’s  profile  mechanism.  SysML  offers 
system  engineers  several  noteworthy  improvements  over  UML,  which  tends  to  be 
software-centric.  These  improvements  include  the  following:  SysML ’s  semantics 
are  more  flexible  and  expressive.  SysML  reduces  UML’s  software-centric 
restrictions  and  adds  two  new  diagram  types,  requirement  and  parametric 
diagrams.  The  former  can  be  used  for  requirements  management;  the  latter  can  be 
used  for  performance  analysis  and  quantitative  analysis.  As  a  result  of  these 
enhancements,  SysML  is  able  to  model  a  wide  range  of  systems,  which  may 
include  hardware,  software,  information,  processes,  personnel,  and  facilities. 

SysML  is  a  smaller  language  that  is  easier  to  learn  and  apply.  Since  SysML 
removes  many  of  UML’s  software-centric  constructs,  the  overall  language  is 
smaller  as  measured  both  in  diagram  types  and  total  constructs.  SysML  allocation 
tables  support  common  kinds  of  allocations.  Whereas  UML  provides  only  limited 
support  for  tabular  notations,  SysML  furnishes  flexible  allocation  tables  that  will 
support  requirements  allocation,  functional  allocation,  and  structural  allocation. 

This  capability  facilitates  automated  Verification  and  Validation  (V&V)  and  gap 
analysis. 
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ATTRIBUTE 

COMMENTS 

Intended  Use 
(cont’d): 

SysML  model  management  constructs  support  models,  views,  and  viewpoints. 

These  constructs  extend  UML’s  capabilities  and  are  architecturally  aligned  with 
IEEE-Std- 147 1-2000  (IEEE  Recommended  Practice  for  Architectural  Description 
of  Software  Intensive  Systems).  SysML  uses  seven  of  UML  2.0’s  thirteen 
diagrams,  and  adds  two  diagrams  (requirements  and  parametric  diagrams)  for  a 
total  of  nine  diagram  types.  SysML  also  supports  allocation  tables,  a  tabular  format 
that  can  be  dynamically  derived  from  SysML  allocation  relationships. 

Community 
of  Usage: 

Systems  Engineering. 

Significant 

Attributes: 

The  Object  Management  Group  announced  the  adoption  of  the  OMG  SysML™ 
on  July  6,  2006  and  the  availability  of  OMG  SysML™  vl.O  in  September  2007. 
With  SysML  you  can  use  Requirement  diagrams  to  efficiently  capture  functional, 
performance  and  interface  requirements,  whereas  with  UML  you  are  subject  to  the 
limitations  of  Use  Case  diagrams  to  define  high-level  functional  requirements. 
Likewise,  with  SysML  you  can  use  Parametric  diagrams  to  precisely  define 
performance  and  mechanical  constraints  such  as  maximum  acceleration,  curb 
weight,  air  conditioning  capacity,  and  interior  cabin  noise  management.  UML 
provides  no  straightforward  mechanism  to  capture  this  essential  performance  and 
mechanical  information. 

Relevance  to 
Our  Work: 

SysML  can  be  used  as  a  conceptual  model  language  format. 

Relevance  of  Form 
for  Our  Product 
Specification 

Relatively  little  -  See  UML. 

References: 

http://www.omgsysml.org/. 

Table  F-20:  Unified  Modeling  Language  (UML). 

ATTRIBUTE 

COMMENTS 

Organization: 

OMG  -  Object  Modeling  Group 

Definition: 

Modeling  notation  and  syntactic  denotation  specification  created  for  software 
development,  but  evolved  into  practical  systematic,  comprehensive  and  formal 
notational  method  for  specification  of  any  system. 

Intended  Use: 

“...  enabling  object  visual  modeling  tool  interoperability.” 

Community 
of  Usage: 

“The  objective  of  UML  is  to  provide  system  architects,  software  engineers, 
and  software  systems  as  well  as  for  modeling  business  and  similar  processes  with 
tools  for  analysis,  design,  and  implementation  of  software -based  systems  as  well 
as  for  modeling  business  and  similar  processes.” 
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ATTRIBUTE 

COMMENTS 

Significant 

Attributes: 

“The  modeling  concepts  of  UML  are  grouped  into  language  units.  A  language  unit 
consists  of  a  collection  of  tightly  coupled  modeling  concepts  that  provide  users  with 
the  power  to  represent  aspects  of  the  system  under  study  according  to  a  particular 
paradigm  or  formalism.  For  example,  the  State  Machines  language  unit  enables 
modelers  to  specify  discrete  event-driven  behavior  using  a  variant  of  the  well-known 
state  charts  formalism,  while  the  Activities  language  unit  provides  for  modeling 
behavior  based  on  a  workflow-like  paradigm.  A  model  contains  three  major 
categories  of  elements:  Classifiers,  events,  and  behaviors.  Each  major  category 
models  individuals  in  an  incarnation  of  the  system  being  modeled.  A  classifier 
describes  a  set  of  objects;  an  object  is  an  individual  thing  with  a  state  and 
relationships  to  other  objects.  An  event  describes  a  set  of  possible  occurrences;  an 
occurrence  is  something  that  happens  that  has  some  consequence  within  the  system. 

A  behavior  describes  a  set  of  possible  executions;  an  execution  is  the  performance  of 
an  algorithm  according  to  a  set  of  rules.  Models  do  not  contain  objects,  occurrences, 
and  executions,  because  those  things  are  the  subject  of  models,  not  their  content. 
Classes,  events,  and  behaviors  model  sets  of  objects,  occurrences,  and  executions 
with  similar  properties.  Value  specifications,  occurrence  specifications,  and 
execution  specifications  model  individual  objects,  occurrences,  and  executions 
within  a  particular  context.  The  distinction  between  objects  and  models  of  objects, 
for  example,  may  appear  subtle,  but  it  is  important.  Objects  (and  occurrences  and 
executions)  are  the  domain  of  a  model  and,  as  such,  are  always  complete,  precise, 
and  concrete.  Models  of  objects  (such  as  value  specifications)  can  be  incomplete, 
imprecise,  and  abstract  according  to  their  purpose  in  the  model.” 

Relevance  to 
Our  Work: 

Highly  relevant  to  the  present  work  in  multiple  ways.  First,  UML  is  a  suitable 
notational  schema  in  which  to  manifest,  represent,  and  document  a  simulation 
conceptual  model  itself.  The  notation  is  powerful  and  versatile,  and  it  has 
extensive  mechanisms  for  specialization  to  alternative  representation  domains. 

As  far  as  is  known,  UML  is  sufficient  (though  not  necessary)  to  specify  any 
simulation  conceptual  model  envisioned  by  the  present  study.  In  addition,  UML 
might  be  used  to  document  the  best-practice  process  and  intended  conceptual 
model  work-product  specification  conceived  by  the  MSG-058  Task  Group. 

Relevance  of  Form 
for  Our  Product 
Specification: 

While  not  used  extensively  within  the  formal  simulation  conceptual  model  process 
and  product  specifications  of  Annexes  G  and  H  below  or  in  the  accompanying  text 
of  Chapters  4,  5  and  6  of  the  document,  UML  could  have  been  used  as  the  primary 
meta-language  to  provide  such  specifications.  As  a  practical  matter,  the  Task 

Group  felt  is  desirable  not  to  adopt  pre-emptively  any  single  notational  schema  lest 
the  practitioner  find  himself  constrained  artificially  to  that  choice.  Nevertheless, 
UML  is  a  candidate  for  future  (alternative)  best-practice  standards  specifications. 

References: 

OMG  Unified  Modeling  Language  TM  (OMG  UML),  UML  Superstructure 
Specification,  v2.3,  May  2010. 

OMG  Unified  Modeling  Language  TM  (OMG  UML),  UML  Infrastructure 
Specification,  v2.3,  May  2010. 

http://www.uml.org/. 

http://www.0mg.0rg/techn0l0gy/d0cuments/m0deling_spec_catal0g.htm#UML. 
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Table  G-1:  Generic  Template  for  Specification  of  Process  Activity. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Step  Name  and  Aliases 

<Denotative  name  of  process  step  appears  here.  > 

Process  Activity  Description 

•  Process  Step  Rationale  /  Need  / 
Motivation 

<Here  an  account  of  the  motivation  of  the  subject  Process  Step 
is  provided,  in  order  that  the  investment  agent  executing  the 
Process  Step  can  have  explicit  record  of  his  expected  intention 
in  executing  the  subject  Process  Step.  > 

Process  Activity  Initiation 

•  Entrance  Criteria 

<This  field  specifies  component  values  of  the  state  of  the 
decision  problem  in  its  entirety  that  are  necessary  and  sufficient 
for  the  subject  Process  Step  to  be  begun  with  high  probability  of 
successful  completion.  > 

Process  Activity  Method 

•  Process  Activity  Procedure 

<In  this  field,  the  investment  evaluation  agent  is  provided 
procedural  guidance  for  the  execution  of  the  subject  Process 

Step.  Note  that  relationships  to  other  activities,  needs  for  tools 
or  information,  and  expected  work-products  are  specified  in 
other  form  records.  Process  Step  procedure  should  be  as  nearly 
as  possible  algorithmically  prescriptive.  Note  however  that  any 
procedure  may  entail  almost  arbitrary  complexity  and  that  the 
procedure  step  in  question  may  be  replaced  with  defining 
notation  other  than  text.  > 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

instruction  cites  relationships  among  activities.  These  may  be 
composition  (is  a  part  of  relationship  in  which  one  Process  Step 
is  executed  as  one  of  several  components  of  a  composite  Process 
Step.  Otherwise,  Process  Step  precedence  (comes-before- 
relationship)  and  Process  Step  successor  (comes-after- 
relationship)  may  be  designated.  This  latter  relationship 
specification  may  be  contingent  allowing  programmatic 
branching,  loop  recursion,  or  self  repetition.  > 

•  Process  Activity  Information  Flow 

<Typically  information  from:  a)  inside  the  process 
(endogenous)  -perhaps  having  been  developed  by  means  of  the 
execution  of  one  or  another  of  the  activities;  or  b)  information 
from  outside  the  decision  process  (exogenous)  may  be  identified 
as  necessary  input  to  a  Process  Step.  > 
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•  Process  Activity  Information  Flow 
(cont’d) 

Alternatively  information  may  flow  out  of  the  Process  Step 
having  been  generated  by  execution  of  the  Process  Step. 

In  either  case  it  is  prudent  to  indicate  the  information  pool 
involved  as  container,  and  the  information  type  specification 
needed  or  generated.  > 

Associated  Entities 

•  Tools 

<Identify  tools  such  as  hardware  or  software  necessary  and 
sufficient  to  complete  the  Process  Step.  In  the  case  of  M&S 
investment  Process  Step,  algorithms  are  likely  tool-types.  > 

•  Actor- Agents 

<Indicate  the  actor  agent  (individual  member  of  one  or  another 
stakeholder  class)  responsible  for  completion  of  the  Process 

Step.  Clearly  Groups  or  anonymous  agents  may  be  designated. 

If  the  responsibility  of  members  of  the  Group  need  to  be 
differentiated,  it  may  be  prudent  to  decompose  the  Process  Step 
into  its  component  parts  in  order  to  reduce  the  cardinality  of 
agents  to  activities  from  N-to-1  to  l-to-l.> 

•  Information  Pools 

<Data  stores  of  any  type  containing  information  used  as  input 
or  generated  as  output  from  a  particular  Process  Step.  May 
contain  intermediate  information  re-used  by  successor  activities, 
or  components  of  the  process  result  compiled  as  residual 
product  documentation.  > 

•  Product  /  Object  /  Artefacts 

<The  principle  intended  output  in  any  form  consequent 
execution  of  the  subject  Process  Step.  Ultimately  an  investment 
decision,  but  meanwhile,  information  artefacts,  qualifications  to 
be  associated  with  the  decision,  or  guidance  as  to  how  the 
resulting  decision  should  be  pursued.  > 

Process  Activity  Completion 

•  Exit  Criteria 

<This  field  specifies  component  values  of  the  state  of  the 
decision  problem  in  its  entirety  that  are  necessary  and  sufficient 
for  the  subject  Process  Step  to  be  considered  finished  with  high 
probability  of  successful  completion.  > 
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Table  G-2:  Conceptual  Model  Process  Activity  1.1  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA1.1  -  Identify  and  Map  Stakeholder  Responsibilities. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  produce  PA  1.1  -  Stakeholder 
Descriptions  which  are  used  to  derive  conceptual  model 
requirements  and  conceptual  model  Knowledge  Needs. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  once  PA1 .2  -  Define  Purpose  and  Intended  Use 
of  M&S  Effort  initiates. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITIES 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Identify  relevant  M&S  responsibilities  based  upon  purpose 
and  intended  use,  constraints,  and  policies. 

•  Map  responsibilities  into  stakeholder  roles  by  category. 

•  Identify  stakeholders  by  organization  or  name  based  upon 

M&S  purpose  and  intended  use,  constraints,  and  policies. 

•  Map  roles  onto  individual  stakeholders. 

•  Document  results  in  P  1.1  -  Stakeholder  Description. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Once  initiated,  may  be  executed  concurrently  with  other  Phase  1 
activities,  or  recursively  in  an  iterative  process  with  activities  in 
other  phases. 

•  Process  Activity  Information  Flow 

Information  from  external  pools  such  as  listed  below  flow  into 
this  process  step.  Information  from  the  other  three  activities  in 
the  first  phase  flow  into  this  activity.  All  information  flow  out 
of  this  activity  is  to  the  P  1.1  -  Stakeholder  Description. 

Associated  Entities 

•  Tools 

No  custom  tools. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

•  Points  of  contact  lists. 

•  Employee  roles. 

•  Organizational  charts. 
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•  Information  Pools  (cont’d) 

•  Personnel  databases. 

•  Referrals. 

•  Resumes. 

•  Biographies,  etc. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  produces  the  P  1.1  -  Stakeholder 

Description. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity  include  the  following: 

•  All  stakeholders  are  identified  and  mapped  to  roles  and 
responsibilities. 

Table  G-3:  Conceptual  Model  Process  Activity  1.2  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA1.2  -  Define  Purpose  and  Intended  Use  of  M&S  Effort. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  produce  PI. 2  -  Need  Statement 
which  is  used  to  derive  conceptual  model  requirements  and 
conceptual  model  Knowledge  Needs. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  upon  stated  or  implied  intent  to  develop  a  model, 
simulation,  or  conceptual  model. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITIES 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Collect  information  from  Information  Pools  below,  relating 
to  purpose  and  intended  use  of  M&S  effort. 

•  Integrate  and  deconflict  collected  information  into  a  self- 
consistent  set  of  descriptions  of  M&S  purpose  and  use. 

•  Provide  information  to  other  activities  in  this  phase. 

•  Translate  M&S  purpose  and  intended  use  into  descriptions 
of  needs  for  the  conceptual  model. 

•  Document  descriptions  of  needs  for  the  conceptual  model 
in  PI  .2  -  Need  Statement. 
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Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Once  initiated,  may  be  executed  concurrently  with  other  Phase  1 
activities,  or  recursively  in  an  iterative  process  with  activities  in 
other  phases. 

•  Process  Activity  Information  Flow 

Information  from  external  pools  such  as  listed  below  flow  into 
this  process  step.  No  information  from  the  other  three  activities 
in  this  phase  flows  into  this  activity.  Information  from  this 
activity  may  flow  into  the  other  three  activities  in  the  first  phase. 
Information  flows  out  of  this  activity  to  the  PI  .2  -  Need 
Statement. 

Associated  Entities 

•  Tools 

No  custom  tools. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Task  orders. 

•  Mission  needs  statements. 

•  User  requirement  documents. 

•  Requests  for  proposal. 

•  Statements  of  work. 

•  Formal  or  informal  directives. 

•  Test  agreements,  etc. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  produces  the  PI. 2  -  Need  Statement. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity  include  the  following: 

•  Purpose  and  intended  use  of  M&S  effort  is  defined. 

Table  G-4:  Conceptual  Model  Process  Activity  1.3  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 


Process  Activity  Name  and  Aliases  PA1 .3  -  Identify  Constraints  on  the  M&S  Effort. 


Process  Activity  Description 


•  Process  Activity  Rationale  /  Need  / 
Motivation 


This  activity  is  necessary  to  produce  PI. 3  -  Constraints  and 
Policies  which  is  used  to  derive  conceptual  model  requirements 
and  conceptual  modeling  knowledge  needs. 
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Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  once  PA1.2  -  Define  Purpose  and  Intended  Use 
of  M&S  Effort  initiates. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITIES 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Collect  information  from  Information  Pools  below,  relating 
to  constraints  on  the  M&S  effort. 

•  Integrate  and  deconflict  collected  information  into  a  self- 
consistent  set  of  descriptions  of  M&S  constraints. 

•  Provide  information  to  the  PA  1.1  activity  for  constraints 
that  impact  selection  of  stakeholders  and  respective 
responsibilities. 

•  Document  Constraints  for  the  conceptual  model  in 

PI. 3  -  Constraints  and  Policies. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Once  initiated,  may  be  executed  concurrently  with  other  Phase  1 
activities,  or  recursively  in  an  iterative  process  with  activities  in 
other  phases. 

•  Process  Activity  Information  Flow 

Information  from  external  pools  such  as  listed  below  flow  into 
this  process  step.  Information  from  PA1.2  may  flow  into  this 
activity.  Information  from  this  activity  may  flow  into  PA  1.1. 
Information  flows  out  of  this  activity  to  PI.  3  -  Constraints  and 
Policies. 

Associated  Entities 

•  Tools 

No  custom  tools. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Documented  resource  constraints. 

•  Senior  stakeholder  preferences  and  requirements. 

•  Planning/budgeting/management  limitations. 

•  Legacy  M&S  preferences  and  availability. 

•  Data  availability. 

•  Enterprise  preferences,  etc. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  PI. 3  -  Constraints  and 

Policies. 
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Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Constraints  of  M&S  effort  are  defined  sufficiently  to 
constrain  the  scope  and  content  of  the  conceptual  model. 

•  Sufficient  contributions  are  made  for  the  development  of 

PI. 3  -  Constraints  and  Policies. 

Table  G-5:  Conceptual  Model  Process  Activity  1.4  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA1.4  -  Identify  Mandatory  Enterprise  Policies. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  produce  PI. 3  -  Constraints  and 

Policies  which  is  used  to  derive  conceptual  model  requirements 
and  conceptual  model  Knowledge  Needs. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  once  PA1 .2  -  Define  Purpose  and  Intended  Use 
of  M&S  Effort  initiates. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITIES 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Collect  information  from  Information  Pools  below,  relating 
to  Enterprise  Policy  Mandates. 

•  Integrate  and  deconflict  collected  information  into  a  self- 
consistent  set  of  mandates. 

•  Provide  information  to  the  PA  1.1  activity  for  mandates  that 
impact  selection  of  stakeholders  and  respective 
responsibilities. 

•  Document  Mandates  for  the  conceptual  model  in 

PI. 3  -  Constraints  and  Policies. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Once  initiated,  may  be  executed  concurrently  with  other  Phase  1 
activities,  or  recursively  in  an  iterative  process  with  activities  in 
other  phases. 
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•  Process  Activity  Information  Flow 

Information  from  external  pools  such  as  listed  below  flow  into 
this  process  step.  Information  from  PA1.2  may  flow  into  this 
activity.  Information  from  this  activity  may  flow  into  PA  1.1. 
Information  flows  out  of  this  activity  to  PI.  3  -  Constraints  and 
Policies. 

Associated  Entities 

•  Tools 

No  custom  tools. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Enterprise  standard  operating  procedures. 

•  Industry  and  government  standards. 

•  Enterprise  executive  mandates  law. 

•  Agency  regulations. 

•  Agency  directives. 

•  Written  policy. 

•  Implied  enterprise  mandates,  etc. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  PI. 3  -  Constraints  and 
Policies. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Enterprise  Mandates  are  defined  sufficiently  to  align  the 
scope  and  content  of  the  conceptual  model  to  mandates. 

•  Sufficient  contributions  are  made  for  the  development  of 

PI. 3  -  Constraints  and  Policies. 

Table  G-6:  Conceptual  Model  Process  Activity  2.1  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA2.1  -  Identify,  Analyze  and  Record  conceptual  Model 

Mission  and  Simulation  Space  Requirements. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  produces  the  requirements  that  will  guide  the 
design  of  the  conceptual  model  and  indirectly  also  the 
conceptual  model  itself. 

•  Process  Activity  Classification 

May  be  classified  depending  on  sensitivity  of  the  content. 
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Process  Activity  Initiation 

•  Entrance  Criteria 

May  begin  as  soon  as  some  of  the  needs  for  the  simulation  are 
clarified  or  some  constraints  or  policies  applicable  to  the 
development  project  are  defined. 

Process  Activity  Method 

•  Process  Activity  Procedure 

This  Process  Activity  will  typically  consist  of  the  following 
sub-activities: 

•  Discussions  with  the  initiator/client  in  order  to  ensure  a 
mutual  understanding  of  the  client’s  needs. 

•  Conferring  with  domain  and  M&S  experts  in  order  to  refine 
the  needs  statement  into  more  detailed  requirements.  This 
activity  may  profitably  be  based  on  descriptions  of  scenarios 
and/or  use  cases. 

•  Consulting  documents  describing  the  mission  domain. 

•  Review  of  earlier  requirement  documents  and  legacy  models 
in  order  to  leverage  earlier  development  efforts. 

•  Documenting  the  elicited  requirements  using  simple  and 
unambiguous  language. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  Process  Activity  initiates  the  definition  phase  of  the 
conceptual  model  development  process.  It  may  be  carried  out 
in  several  passes  after  PA2.2  -  Requirement  Verification  has 
revealed  incompleteness,  incorrectness  or  ambiguities. 

•  Process  Activity  Information  Flow 

The  activity  takes  as  inputs  PI. 2  -  Need  Statement  and 

PI. 3  -  Constraints  and  Policies  and  produces  a  preliminary 
requirement  specification. 

Associated  Entities 

•  Tools 

Requirements  management  tool. 

•  Actor- Agents 

Conceptual  model  producer,  domain  SMEs,  M&S  SMEs. 

•  Information  Pools 

Legacy  requirements  and  conceptual  models,  descriptions  of 
military  equipment  and  documentation  of  military  tactics, 
techniques,  and  procedures. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  produces  a  preliminary  requirement 
specification  to  be  verified  in  PA2.2. 

Process  Activity  Completion 

•  Exit  Criteria 

All  relevant  requirements  for  the  conceptual  model  have  been 
identified  and  documented. 
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Table  G-7:  Conceptual  Model  Process  Activity  2.2  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 

Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA2.2  -  Verify  Requirements  with  Respect  to  Needs, 

Constraints  and  Policies. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  will  ensure  that  all  needs  are  accounted  for  and 
constraints  and  policies  are  adequately  described  in  the 
requirement  specification. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  At  least  some  requirements  must  have  been  documented 
prior  to  starting  this  activity. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PREEIMINARY  or  PREFATORY  ACTIVITIES 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Specify  the  quality  attributes  that  the  requirement 
specification  shall  satisfy. 

•  Review  and  modify  the  conceptual  model  requirement 
specification  to  ensure  that  the  chosen  quality  attributes  are 
satisfied. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  follows  the  PA2.1  -  Requirements  Definition  and 
is  followed  PA2.3  -  Synergize  Requirements. 

•  Process  Activity  Information  Flow 

The  activity  takes  as  inputs  PI. 2  -  Need  Statement  and 

PI. 3  -  Constraints  and  Policies  and  updates  the  preliminary 
requirement  specification.  In  addition,  V&V  evidence  must  be 
added  to  Meta  data  of  the  conceptual  model. 

Associated  Entities 

•  Tools 

Requirement  management  tool. 

•  Actor- Agents 

Producer  (requirement  engineer). 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Preliminary  requirement  specification. 

•  Meta  data. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  updates  the  preliminary  requirement 
specification. 
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Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  All  requirements  have  been  evaluated  with  respect  to  chosen 
quality  attributes. 

•  Any  identified  discrepancies  have  been  rectified. 

Table  G-8:  Conceptual  Model  Process  Activity  2.3  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 

Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA2.3  -  Synergize  Conceptual  Model,  Mission  and  Simulation 
Space  Requirements. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Reconciling  any  incompatibilities  between  conceptual  model, 
mission  and  simulation  space  requirements. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  At  least  some  requirements  of  different  categories  must  have 
been  defined. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Review  and  modify  the  conceptual  model  requirement 
specification  to  ensure  compatibility  between  conceptual 
model,  mission,  and  simulation  space  requirements. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  follows  PA2.2  and  is  followed  by  PA2.4. 

•  Process  Activity  Information  Flow 

This  Process  Activity  takes  the  preliminary  requirement 
specification  produced  by  PA2.2  as  input  and  produces 

P2.1  -  Conceptual  Model  Requirement  Specification. 

Associated  Entities 

•  Tools 

Requirement  management  tool. 

•  Actor- Agents 

Producer  (requirement  engineer). 

RTO-TR-MSG-058 


G  - 11 


ANNEX  G  -  CONCEPTUAL  MODELING  PROCESS  ACTIVITY  DESCRIPTION 


ORGANIZATION 


•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Preliminary  requirement  specification. 

•  Product  /  Object  /  Artefacts 

P2.1  -  Conceptual  Model  Requirement  Specification. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  All  requirements  have  been  evaluated  for  compatibility  with 
respect  to  requirements  of  the  other  categories. 

•  P2.1  has  been  completed. 

Table  G-9:  Conceptual  Model  Process  Activity  2.4  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA2.4  -  Derive  Mission  and  Simulation  Space  Knowledge  Needs. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

The  purpose  of  this  Process  Activity  is  to  communicate  to  the 
conceptual  model  producer  what  knowledge  must  be  acquired 
in  order  to  design  and  build  a  conceptual  model  that  will  serve 
its  intended  purpose. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  At  least  some  conceptual  model  requirement  must  have  been 
identified  and  documented. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Analyze  the  requirement  specification  in  order  to  derive 
knowledge  needs. 

•  Document  knowledge  needs. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  Process  Activity  follows  the  PA2.3  and  is  the  final  activity 
in  Process  Phase  2. 

•  Process  Activity  Information  Flow 

This  Process  Activity  uses  P2.1  -  Conceptual  Model 

Requirement  Specification  as  input  and  produces  P2.2  - 
Conceptual  Model  Knowledge  Acquisition  Needs  as  output. 
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ANNEX  G  -  CONCEPTUAL  MODELING  PROCESS  ACTIVITY  DESCRIPTION 


Associated  Entities 

•  Tools 

None. 

•  Actor- Agents 

Producer  (knowledge  engineer). 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Legacy  knowledge. 

•  Need  descriptions. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  produces  P2.2  -  Conceptual  Model 
Knowledge  Acquisition  Needs. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  An  exhaustive  list  of  knowledge  elements  needed  to  design 
and  build  the  desired  conceptual  model  has  been 
documented  in  P2.2. 

Table  G-10:  Conceptual  Model  Process  Activity  3.1  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 

Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA3.1  -  Identify  Authoritative  Knowledge  Sources. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  about  identifying  authoritative  knowledge 
sources  to  fetch  correct  and  authoritative  information  that 
describes  a  certain  domain,  for  example  through  books,  papers, 
tutorials,  interviewing  the  SMEs,  etc. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  once  P2.1  -  Conceptual  Model  Requirement 
Specification  and  P2.2  -  Conceptual  Model  Knowledge 
Acquisition  Needs  exist. 

Process  Activity  Method 

•  Process  Activity  Procedure 

There  is  no  specific  methodology  for  identifying  appropriate 
sources  for  KA,  but  here  is  a  couple  of  recommendations: 

•  Having  a  deeper  understanding  of  the  problem  domain  and 
(preferably)  having  experience  of  the  particular  area  are 
necessary  qualities  for  success. 
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ORGANIZATION 


•  Process  Activity  Procedure  (cont’d) 

•  Rely  only  on  authoritative  knowledge  sources,  those 
authorised  by  some  organisation/authority  beforehand 
(who  this  person  or  agency  should  be  is  beyond  the  scope 
of  this  report). 

•  These  sources  can  be  anything  from  books,  web  information, 
papers,  regulations  documents,  pictures,  maps,  and  case 
studies,  but  perhaps  most  important  of  all  interviews  with 
Subject-Matter  Experts  (SMEs). 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  may  be  initiated  as  soon  as  the  inputs 

P2.1  -  Requirement  Specification  and  P2.2  -  Conceptual  Model 
Knowledge  Acquisition  Needs  are  available.  But  it  must  be  done 
before  activity  PA3.4  -  Gather,  Structure  and  Document 
Knowledge  begins. 

•  Process  Activity  Information  Flow 

This  activity  takes  as  inputs  P2.1  -  Conceptual  Model 
Requirement  Specification  and  P2.2  -  Conceptual  Model 
Knowledge  Acquisition  Needs  and  produces  a  list  of 
authoritative  knowledge  sources  which  corresponds  to 
requirements  and  needs  identified  in  Phase  2. 

Associated  Entities 

•  Tools 

No  custom  tools. 

•  Actor- Agents 

No  specific  actors  or  agents  has  been  identified,  however 
existence  of  some  organisation  or  authority  who  can  point  out 
authoritative  knowledge  sources  is  of  great  benefit. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  List  of  authoritative  knowledge  sources  for  different  military 
activities. 

•  Simulation  expertise,  etc. 

•  Points  of  contact  lists. 

•  List  of  SMEs. 

•  Employee  roles. 

•  Organizational  charts. 

•  Biographies,  etc. 

•  Product  /  Object  /  Artefacts 

The  final  product  of  this  activity  will  be  a  list  of  authoritative 
knowledge  sources  for  a  certain  kind  of  knowledge. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  at  least  one  authoritative  knowledge  sources  adequate 
for  the  certain  kind  of  knowledge  has  been  identified. 
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Table  G-11:  Conceptual  Model  Process  Activity  3.2  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA3.2  -  Search  for  the  Reusable  Knowledge  in  the  Conceptual 
Model  Repository. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Given  that  a  conceptual  model  repository  already  exists,  no 
acquisition  of  new  knowledge  is  justified  before  checking  if  the 
required  conceptual  model  already  is  either  partly  or  completely 
modelled  and  stored  in  the  conceptual  model  repository. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  once  P2.1  -  Conceptual  Model  Requirement 
Specification  and  P2.2  -  Conceptual  Model  Knowledge 
Acquisition  Needs  exist. 

Process  Activity  Method 

•  Process  Activity  Procedure 

There  is  no  specific  methodology  for  identifying  appropriate 
sources  for  KA,  but  here  are  a  couple  of  recommendations. 

The  list  of  needs  and  requirements  will  be  the  foundation  for 
building  the  necessary  queries  to  the  repository: 

•  Analyze  P2.1  -  Conceptual  Model  Requirement 

Specification  and  P2.2  -  Conceptual  Model  Knowledge 
Acquisition  Needs  to  find  syntactic  and/or  semantic  key 
words  for  the  search. 

•  Do  search  in  an  already  existing  conceptual  model 
repository  for  the  reusable  knowledge. 

Keep  in  mind  that  several  qualitative  properties  are  critically 
important  to  search  and  find  either  the  reusable  knowledge 
component  (part  of  a  conceptual  model)  or  a  complete 
conceptual  model  fulfilling  a  specific  need: 

•  One  is  to  try  to  model  knowledge  in  smaller  components  that 
makes  reusability  easier. 

•  The  other  property  is  to  have  a  degree  of  formalisation  and 
semantic  description  that  makes  it  possible  to  compose 
smaller  components  for  building  the  needed  conceptual 
model. 

•  The  third  is  to  have  good  Meta  data  addressing  artefacts  in 
the  conceptual  model  Repository;  this  makes  it  possible  to 
easily  find  the  knowledge  which  corresponds  to  the  need. 
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Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  may  be  initiated  as  soon  as  the  inputs 

P2.1  -  Conceptual  Model  Requirement  Specification  and 

P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs  are 
available.  But  it  must  be  done  before  activity  PA3.4  -  Gather, 
Structure  and  Document  Knowledge  begins. 

•  Process  Activity  Information  Flow 

This  activity  takes  as  inputs  P2.1  -  Conceptual  Model 
Requirement  Specification  and  P2.2  -  Conceptual  Model 
Knowledge  Acquisition  Needs  and  produces  a  list  of 
authoritative  knowledge  sources  which  corresponds  to 
requirements  and  needs  identified  in  Phase  2. 

Associated  Entities 

•  Tools 

Query  making  and  repository  searching  tools. 

•  Actor- Agents 

No  specific  actors  or  agents  have  been  identified. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Reusable  knowledge  components  which  partly  or  completely 
fulfill  the  need  may  be  found  as  an  intermediate  product. 

•  Product  /  Object  /  Artefacts 

The  final  product  of  this  activity  will  be  either: 

•  A  positive  answer  that  the  required  conceptual  model  is 
found  in  the  conceptual  model  repository; 

•  Reusable  knowledge  components  which  only  partly  fulfill 
the  need  has  been  found;  or 

•  A  negative  answer  about  nothing  of  value  for  the  specific 
need  was  found. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  the  search  is  done  and  adequate  result  has  been 
retrieved. 

Table  G-12:  Conceptual  Model  Process  Activity  3.3  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 

Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA3.3  -  Identify  Knowledge  Gaps  and  Bounds. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 

This  activity  concerns  whether  the  knowledge  retrieved  from  an 

Motivation 

existing  conceptual  model  repository  is  in  accordance  with  the 
requirements  and  needs  or  not. 

G  - 16 


RTO-TR-MSG-058 


dMNATO 
WP  I  OTAN 


ANNEX  G  -  CONCEPTUAL  MODELING  PROCESS  ACTIVITY  DESCRIPTION 


•  Process  Activity  Rationale  /  Need  / 
Motivation  (cont’d) 

The  reusability  of  already  gathered  knowledge  will  be  examined 
to  see  if  they  can  be  used  for  the  new  purpose. 

This  outcome  aids  in  identifying  what  is  missing. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  This  activity  will  happen  (will  be  considered)  only  if  the 
result  of  the  previous  activity  PA3.2  -  Search  for  the 

Reusable  Knowledge  is  case  b),  which  is  the  knowledge 
components  found  in  the  conceptual  model  repository  partly 
fulfill  the  need. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  If  the  result  of  PA3.2  is  case  a)  “the  required  knowledge  is 
found  in  the  conceptual  model  repository”  end  this  activity 
immediately  and  initiate  PA3.5. 

•  If  the  result  of  PA3.2  is  case  c)  “nothing  of  value  for  the 
specific  need  was  found”  end  this  activity  immediately  and 
initiate  PA3.4. 

•  If  the  result  of  PA3.2  is  case  b)  “reusable  knowledge 
components  which  only  partly  fulfil  the  need  has  been 
found”;  then  the  result  has  to  be  analyzed  and  compared 
with  the  need  to  identify  knowledge  gaps,  i.e.,  what 
part/parts  are  missing. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  will  be  initiated  after  PA3.2  is  done.  Depending  to 
the  result  it  will  either  be  followed  by  PA3.4  or  PA3.5. 

•  Process  Activity  Information  Flow 

This  activity  takes  as  inputs  P2.2  -  Conceptual  Model 

Knowledge  Acquisition  Needs  and  the  result  of  PA3.2  -  Search 
for  the  Reusable  Knowledge,  and  if  no  knowledge  gap  is 
identified  it  will  initiate  PA3.5,  but  if  significant  knowledge  is 
still  missing  will  produce  an  intermediate  document  addressing 
that  gap  which  will  be  used  of  PA3.4  -  Gather,  Structure  and 
Document  Knowledge. 

Associated  Entities 

•  Tools 

Knowledge  comparison  tools. 

•  Actor- Agents 

Knowledge  engineer,  SME. 
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•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Intermediate  result  from  PA3.2,  P2.1  and  P2.2. 

•  Product  /  Object  /  Artefacts 

The  final  product  of  this  activity  will  either  be: 

•  No  knowledge  gaps  identified;  or 

•  A  notion  of  what  kind  of  information  is  missing  and  a  list 
of  authorized  knowledge  sources  for  KA. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  knowledge  comparison  is  done  and  the  gaps  are 
addressed. 

Table  G-13:  Conceptual  Model  Process  Activity  3.4  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA3.4  -  Gather,  Structure  and  Document  Knowledge. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  about  acquiring  certain  knowledge  which  often  is 
not  documented  anywhere  but  only  available  through  Subject- 
Matter  Experts  (SME).  This  acquired  knowledge  will  then  be 
structured  and  documented  for  further  use. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  When  the  result  of  PA3.2  -  Search  for  the  Reusable 
Knowledge  has  been  case  c)  “nothing  of  value  for  the 
specific  need  was  found”;  or 

•  When  PA3.3  -  Identify  Knowledge  Gaps  and  Bounds  has 
ended. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  The  first  step  in  this  activity  is  about  gathering  knowledge. 
Information  sources  for  military  activities  can  be  anything 
from  instructions,  books,  military  doctrines,  military 
scenarios,  case  studies  to  military  experts. 
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•  Process  Activity  Procedure  (cont’d) 

However,  the  information  that  is  needed  for  a  certain 
purpose  is  often  not  documented  anywhere  and  is  only 
available  through  SMEs.  Below  we  provide  examples  of 
techniques  that  can  be  used  for  this  kind  of  knowledge 
elicitation  (mainly  through  interviews): 

•  Unstructured:  The  SME  has  a  general  discussion  of  the 
domain,  designed  to  provide  a  list  of  topics  and 
concepts. 

•  Structured:  The  interviewer  asks  the  SME  or  end  user 
questions  relating  to  a  specific  topic. 

•  Problem-solving:  The  SME  is  provided  with  a  real-life 
problem,  something  that  they  deal  with  during  their 
working  life  and  are  then  asked  to  solve  it.  As  the  expert 
does  so,  they  are  required  to  describe  each  step,  and  the 
reasons  for  doing  it. 

•  Prototyping:  The  SME  is  asked  to  evaluate  a  prototype 
of  a  system. 

•  Simulation:  The  SME  is  asked  to  use  a  simulator  so  that 
the  SME’s  behaviors  can  be  observed. 

•  Dialogue:  The  SME  interacts  with  a  client,  in  the  way 
that  they  would  normally  do  during  their  normal  work 
routine. 

•  Sample  lecture  preparation:  The  SME  prepares  a  lecture, 
and  the  knowledge  engineer  analyses  its  content. 

•  Questionnaires:  These  are  useful  when  the  knowledge 
is  to  be  gathered  from  several  different  subject-matter 
experts. 

•  When  the  knowledge  is  acquired  a  methodology  must  be 
chosen  to  structure  the  knowledge. 

•  Finally  the  gathered  and  structured  knowledge  must  be 
documented  for  further  use  and  reuse. 

•  Last  but  not  least  must  conceptual  model  Meta  data  product 
be  update  with  new  information. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  will  be  initiated  either  by  PA3.2  -  Search  for  the 
Reusable  Knowledge  or  after  PA3.3  -  Identify  Knowledge  Gaps 
and  Bounds  is  done.  This  activity  must  be  done  before  PA3.5  - 
Generate/Extend  a  Domain  Ontology  begins. 

•  Process  Activity  Information  Flow 

This  activity  takes  the  intermediate  product  generated  in 

PA3.3  -  Identify  Knowledge  Gaps  and  Bounds  as  input  and 
produces  another  intermediate  product  called  structured 
knowledge  corpus. 
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Associated  Entities 

•  Tools 

•  Knowledge  Acquisition  (KA)  tools. 

•  Structuring  tools. 

•  Actor- Agents 

•  Knowledge  Acquisition  expert. 

•  Knowledge  engineer. 

•  Information  Pools 

Intermediate  result  from  PA3.3,  P2.1  and  P2.2.  Information 
sources  for  military  activities  can  be  anything  from  instructions, 
books,  military  doctrines,  military  scenarios,  case  studies  to 
military  experts.  However,  the  information  that  is  needed  for  a 
certain  purpose  is  often  not  documented  anywhere  and  is  only 
available  through  SMEs. 

•  Product  /  Object  /  Artefacts 

The  final  product  of  this  step  is  some  structured  and  documented 
information  gathered  to  fulfil  a  certain  need  of  knowledge. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  the  needed  knowledge  is  gathered,  structured  and 
documented. 

Table  G-14:  Conceptual  Model  Process  Activity  3.5  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA3.5  -  Generate/Extend  a  Domain  Ontology. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  covers  structuring,  tagging,  and  storing  the 
gathered  information  either  as  new  domain  ontology  or  as  an 
extension  to  an  existing  one. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  be  initiated  by  PA3.3  -  Identify  Knowledge  Gaps  and 
Bounds. 

•  When  PA3.4  -  Gather,  Structure  and  Document  Knowledge 
has  ended  and  the  intermediate  product  Structured 

Knowledge  corpus  is  available. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 
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•  Process  Activity  Procedure  (cont’d) 

•  New  knowledge  most  likely  will  introduce  new  military 
concepts,  properties,  relations,  and  constraints  which  should 
be  stored  in  some  kind  of  knowledge  base  for  future  use  and 
reuse. 

•  Check  if  ontology/ontologies  for  the  current  subject  already 
exist,  and  in  that  case  update  the/those  ontology/ontologies 
with  the  most  recent  acquired  knowledge. 

•  If  no  ontology  exists  for  the  current  subject/domain  one  may 
be  created. 

•  There  are  different  methodologies  for  integrating  these  new 
concepts  into  existing  ontologies  as  well  as  for  creating  new 
ones.  The  appropriate  creation  methodology  will  depend 
upon,  and  be  influenced  by,  the  requirements  and  design 
criteria  that  exist.  Examples  of  these  for  such  an  ontological 
knowledge  base  may  be: 

•  Flexibility; 

•  Adaptability; 

•  Traceability; 

•  Machine  readability; 

•  Interoperability;  and 

•  Reusability  for  multiple  applications;  or  might  simply 
be  rapid  and  easy  development. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

•  The  previous  activities  captured  and  documented  new 
knowledge  about  a  certain  military  activity  that  did  not  already 
exist  in  the  conceptual  model  repository.  As  soon 

as  this  intermediate  product  (new  documented  knowledge) 
is  available  this  activity  can  begin. 

•  This  activity  may  indicate  that  the  acquiring  and 
documentation  of  knowledge  is  done  and  ready  for  review, 
and  thereby  PA3.6  may  be  initiated. 

•  Process  Activity  Information  Flow 

This  activity  takes  the  intermediate  product  generated  in  PA3.4 
called  structured  knowledge  corpus  and  either  produces  a  new 
ontology  or  update/extend  an  existing  one. 

Associated  Entities 

•  Tools 

•  Ontology  engineering  tools. 

•  Ontology  creation  tools. 

•  Ontology  integration  tool. 

•  Actor- Agents 

•  Ontology  experts. 

•  Conceptual  modeler. 
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•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Intermediate  result  from  PA3.3. 

•  Structured  knowledge  corpus  created  in  PA3.4. 

•  Existing  ontology  repository. 

•  Knowledgebase. 

•  Product  /  Object  /  Artefacts 

The  final  product  of  this  activity  will  either  be: 

•  A  new  domain  ontology;  or 

•  An  updated/extended  version  of  an  existing  ontology, 
covering  the  latest  acquired  knowledge. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  domain  ontology  is  build;  or 

•  An  existing  one  is  updated/extended. 

Table  G-15:  Conceptual  Model  Process  Activity  3.6  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA3.6  -  Review  Validity  of  Knowledge  with  Respect  to  the 
Authoritative  Knowledge  Sources. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  discusses  and  examines  the  validity  of  acquired 
knowledge  with  respect  to  authoritative  knowledge  sources. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activity,  availability  of  information  and  establishment  of 
operational  capability: 

•  Will  be  initiated  when  PA3.5  -  Generate/Extend  a  Domain 
Ontology  is  done  and  the  acquired  knowledge  is  ready  for 
review. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  validity  of  acquired  knowledge  with  respect  to  authoritative 
knowledge  sources  can  be  done  using  different  V&V 
methodologies,  e.g.,  GM-V&V.  The  following  PRELIMINARY 
or  PREFATORY  ACTIVITY  establish  the  context  within  which 
the  bulk  of  direct  conceptual  model  population  will  occur: 
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•  Process  Activity  Procedure  (cont’d) 

•  It  is  about  checking  -  preferably  performed  by  a  VV&A 
agent  -  with  the  experts,  whose  realities  have  been  captured 
and  documented,  to  see  if  the  documented  knowledge  is 
correct  and  completely  represents  the  activity. 

•  Examine  whether  the  result  of  the  knowledge  acquisition 
phase  is  acceptable  to  the  owner  of  the  mission  space 
(the  SME). 

•  An  ontology  expert  may  also  examine  if  the  generation  or 
integration  of  the  ontology  is  done  correctly. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  may  be  initiated  as  soon  as  the  activity  PA3.5  - 
Generate/Extend  a  Domain  Ontology  is  done  and  the  acquired 
knowledge  or  the  ontology  is  ready  for  review.  And  when  the 
acquired  knowledge  or  the  ontology  is  validated  this  phase  is 
completed. 

•  Process  Activity  Information  Flow 

This  activity  takes  P2.2  -  Conceptual  Model  Knowledge 
Acquisition  Needs  and  the  intermediate  product  from  PA3.5  the 
ontology,  and  produce  the  P3.1  -  Validated  Knowledge. 

Associated  Entities 

•  Tools 

•  V&V  tools. 

•  Ontology  reviewing  tools. 

•  Actor- Agents 

•  V&V  agents. 

•  SMEs. 

•  Ontology  experts. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  The  ontology  created,  updated  or  extended  as  a  result  of 
PA3.5. 

•  Existing  ontology  repository  or  knowledge  base. 

•  P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs. 

•  List  of  authoritative  knowledge  sources  produced  as  an 
intermediate  product  in  PA3. 1 . 

•  Product  /  Object  /  Artefacts 

This  is  the  last  activity  and  the  last  check  within  Phase  3, 
and  artefacts  which  pass  this  check  are  qualified  to  go  to  the 
next  phase  of  the  conceptual  modeling  process. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  the  acquired  knowledge  is  validated. 
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Table  G-16:  Conceptual  Model  Process  Activity  4.1  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA4.1  -  Search  for  Existing  Conceptual  Models  that  May  be 
Partially  of  Fully  Re-Used  to  Support  the  Current  Conceptual 
Model  Development. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  identifies  the  need  to  partially  or  fully  reuse 
existing  conceptual  models. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  when  PA2.3  has  substantial  progress  and  when 
PA2.1  -  Conceptual  Model  Requirement  Specification  has 
substantial  input  to  start  identifying  search  criteria  for  reuse. 

•  A  repository  with  conceptual  models  that  have  Meta  data 
descriptions  that  is  relevant  to  designing  conceptual  models. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Parse  P2.1  -  Conceptual  Model  Requirement  Specification 
to  become  acquainted  with  what  design  characteristics  are 
required. 

•  Identify  search  criteria  based  upon  these  required  design 
characteristics  and  search  for  candidate  conceptual  model. 

•  If  conceptual  model  compositions  have  already  been 
identified  in  the  preliminary  conceptual  model  design, 
search  for  conceptual  models  with  similar  design 
characteristics. 

•  Identify  suitability  for  reuse  based  on  criteria  listed  in  the 
conceptual  model  Requirements  Specification. 

•  Record  or  update  the  found  conceptual  models  to  the 
preliminary  conceptual  model  design  artefact. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

This  activity  is  executed  at  least  once  and  may  be  executed 
iteratively  after  new  inputs  to  the  preliminary  conceptual  model 
design  during  PA4.2,  PA4.3,  PA4.4  or  PA4.5  or  after  the  failure 
to  meet  the  conceptual  model  requirements  during  PA4.6 
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•  Process  Activity  Sequence  and 
Control-Flow  (cont’d) 

evaluation  or  after  the  addition  of  requirements  in  P2.1  from 
either  some  build  experience  in  PA5.1,  the  arrival  of  new 
stakeholders,  the  evolution  to  different  conceptual  model 
characteristics  (quality,  utility,  formality,  abstractness),  etc. 

•  Process  Activity  Information  Flow 

Information  from  P2.1  -  Conceptual  Model  Requirement 
Specification  and  from  external  information  pools  flows  into 
this  activity.  Information  from  this  activity  flows  into  the 
preliminary  conceptual  model  design  and  eventually  into 

P4.1  -  Conceptual  Model  Design  if  selected. 

Associated  Entities 

•  Tools 

No  custom  tools. 

•  Actor- Agents 

•  Producer. 

•  Conceptual  model  developer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification, 
preliminary  conceptual  model  design,  preliminary 
conceptual  model,  existing  conceptual  models. 

•  Conceptual  models  that  have  relevance  in  the  mission  space. 

•  Expected  views  driven  by  Stakeholder  roles. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  a  preliminary  conceptual 
model  design. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Some  (not  necessarily  all  or  definitely)  conceptual  models 
have  been  found  and  recorded  to  the  preliminary  conceptual 
model  design. 

Table  G-17:  Conceptual  Model  Process  Activity  4.2  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA4.2  -  Identify  and  Select  Conceptual  Primitives  and  Model 
Kinds  to  Represent  Acquired  Knowledge. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  select  suitable  conceptual  primitives 
that  will  capture  the  knowledge  elements  and  model  kinds  that 
will  organize  the  conceptual  primitives.  This  activity  is  necessary 
to  be  intentionally  selective  on  the  conceptual  primitive  and 
model  kind  options.  This  activity  is  an  investment  against  the  risk 
of  uninformed  use  of  conceptual  primitives  and  model  kinds. 
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Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  when  PA2.3  has  substantial  progress  and 

P2.1  -  Conceptual  Model  Requirement  Specification  has 
valuable  input. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Parse  P2.1  -  Conceptual  Model  Requirement  Specification 
to  become  acquainted  with  the  type  of  knowledge  to  be 
captured  and  organized. 

•  Analyze  conceptual  model  characteristics  requirements  from 
P2. 1  -  Conceptual  Model  Requirement  Specification  to  derive 
the  implications  on  conceptual  primitives  and  model  kinds. 

•  Survey  conceptual  primitive  and  model  kind  options  either 
from  the  literature  or  from  experience. 

•  Make  an  elective  choice  of  conceptual  primitives  and  model 
kinds  that  suit  the  requirements  and  that  make  a  coherent 
conceptual  model  composite  combination. 

•  If  views  have  been  selected  in  the  preliminary  conceptual 
model  design,  select  model  kinds  that  represent  these  views. 

•  If  model  kinds  have  been  selected  in  the  preliminary 
conceptual  model  design,  select  conceptual  primitives  that 
compose  these  model  kinds. 

•  If  conceptual  primitives  have  been  selected  in  the 
preliminary  conceptual  model  design,  select  model  kinds 
that  will  use  these  conceptual  primitives. 

•  Record  or  update  the  selected  conceptual  primitives  and 
model  kinds  in  a  preliminary  conceptual  model  design 
artefact. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Executed  at  least  once  and  may  be  executed  iteratively  after  new 
inputs  to  the  preliminary  conceptual  model  design  during  PA4.1, 
PA4.3,  PA4.4  or  PA4.5  or  after  the  failure  to  meet  the 
conceptual  model  requirements  during  PA4.6  evaluation  or  after 
the  addition  of  requirements  in  P2.1  from  either  some  build 
experience  in  PA5.1,  the  arrival  of  new  stakeholders,  the 
evolution  to  different  conceptual  model  characteristics  (quality, 
utility,  formality,  abstractness),  etc. 
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•  Process  Activity  Information  Flow 

Information  from  P2.1  -  Conceptual  Model  Requirement 
Specification  and  from  external  information  pools  flows  into  this 
activity.  Information  from  this  activity  flows  into  the 
preliminary  conceptual  model  design  and  eventually  into 

P4.1  -  Conceptual  Model  Design. 

Associated  Entities 

•  Tools 

Specific  modeling  tools  can  help  to  select  coherent  conceptual 
model  composite  combinations.  Tool  availability  is  likely  to 
influence  the  design  choices. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification. 

•  Preliminary  conceptual  model  design. 

•  Preliminary  conceptual  model. 

•  Existing  conceptual  models. 

•  Literature  on  conceptual  primitives  and  model  kinds. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  a  preliminary  conceptual 
model  design. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Some  (not  necessarily  all  or  definitely)  conceptual  primitives 
and  model  kinds  have  been  selected  and  recorded  to  the 
preliminary  conceptual  model  design. 

Table  G-18:  Conceptual  Model  Process  Activity  4.3  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA4.3  -  Select  Formalism(s)  for  Conceptual  Model 

Specification. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  select  the  formalism(s)  that  will  be 
followed  in  the  build  process.  This  activity  is  necessary  to  be 
intentionally  selective  on  the  formalism  options.  This  activity  is 
an  investment  against  the  risk  of  uninformed  use  of  formalisms. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 
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•  Entrance  Criteria  (cont’d) 

•  May  begin  when  PA2.3  has  substantial  progress. 

•  P2.1  -  Conceptual  Model  Requirement  Specification  has 
valuable  input. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PREFIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Parse  P2.1  -  Conceptual  Model  Requirement  Specification 
to  become  acquainted  with  the  type  of  knowledge  to  be 
modeled. 

•  Analyze  conceptual  model  characteristics  requirements  from 
P2.1  -  Conceptual  Model  Requirement  Specification  to 
derive  the  implications  on  formalisms. 

•  If  a  formalism  has  been  mandated  by  policies,  record  it  to 
the  preliminary  conceptual  model  design. 

•  Survey  formalism  options  either  from  the  literature  or  from 
experience. 

•  Analyze  the  preliminary  conceptual  model  design  to  derive 
appropriate  formalisms  to  fit  the  conceptual  primitives, 
model  kinds  and  views. 

•  Make  an  elective  choice  of  formalism(s)  that  suit  the 
requirements  and  that  make  a  coherent  conceptual  model 
composite  combination. 

•  Record  or  update  the  selected  formalism(s)  in  the 
preliminary  conceptual  model  design  artefact. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Executed  at  least  once  and  may  be  executed  iteratively  after  new 
inputs  to  the  preliminary  conceptual  model  design  during  PA4.1, 
PA4.2,  PA4.3  or  PA4.5  or  after  the  failure  to  meet  the 
conceptual  model  requirements  during  PA4.6  evaluation  or  after 
the  addition  of  requirements  in  P2.1  from  either  some  build 
experience  in  PA5.1,  the  arrival  of  new  stakeholders,  the 
evolution  to  different  conceptual  model  characteristics  (quality, 
utility,  formality,  abstractness),  etc. 

•  Process  Activity  Information  Flow 

Information  from  P2.1  -  Conceptual  Model  Requirement 
Specification  and  from  external  information  pools  flows  into  this 
activity.  Information  from  this  activity  flows  into  the 
preliminary  conceptual  model  design  and  eventually  into 

P4.1  -  Conceptual  Model  Design. 

Associated  Entities 

•  Tools 

Specific  modeling  tools  can  help  to  select  coherent  conceptual 
model  composite  combinations.  Tool  availability  is  likely  to 
influence  the  design  choices. 
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•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification. 

•  Preliminary  conceptual  model  design. 

•  Preliminary  conceptual  model. 

•  Existing  conceptual  models,  literature  on  formalisms. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  a  preliminary  conceptual 
model  design. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  At  least  one  formalism  has  been  selected  and  recorded  to 
the  preliminary  conceptual  model  design. 

Table  G-19:  Conceptual  Model  Process  Activity  4.4  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA4.4  -  Select  Views  to  Support  Stakeholders. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  select  the  views  that  will  fit  the 
purpose  of  the  different  stakeholders. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  May  begin  when  PA2.3  has  substantial  progress  and 

P2.1  -  Conceptual  Model  Requirement  Specification  has 
valuable  input. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Parse  P2.1  -  Conceptual  Model  Requirement  Specification 
to  become  acquainted  with  the  type  of  knowledge  to  be 
communicated. 

•  Analyze  the  stakeholders’  view  requirements  from 

P2.1  -  Conceptual  Model  Requirement  Specification  to 
derive  the  implications  on  view  selection. 
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•  Process  Activity  Procedure  (cont’d) 

•  Survey  view  options  either  from  the  literature  or  from 
experience. 

•  If  formalisms  have  been  selected  in  the  preliminary 
conceptual  model  design,  analyze  the  impact  of  the 
formalisms  on  the  discretionary  specification  of  views. 

•  Make  an  elective  choice  of  views  that  support  the 
stakeholders’  requirements. 

•  Record  or  update  the  selected  views  in  the  preliminary 
conceptual  model  design  artefact. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Executed  at  least  once  and  may  be  executed  iteratively  after  new 
inputs  to  the  preliminary  conceptual  model  design  during  PA4.1, 
PA4.3  or  PA4.5  or  after  the  failure  to  meet  the  conceptual  model 
requirements  during  PA4.6  evaluation  or  after  the  addition  of 
requirements  in  P2.1  from  either  some  build  experience  in 

PA5.1,  the  arrival  of  new  stakeholders,  the  evolution  to  different 
conceptual  model  characteristics  (quality,  utility,  formality, 
abstractness),  etc. 

•  Process  Activity  Information  Flow 

Information  from  P2.1  -  Conceptual  Model  Requirement 
Specification  and  from  external  information  pools  flows  into 
this  activity.  Information  from  this  activity  flows  into  the 
preliminary  conceptual  model  design  and  eventually  into 

P4.1  -  Conceptual  Model  Design. 

Associated  Entities 

•  Tools 

Specific  modeling  tools  can  help  to  select  coherent  conceptual 
model  composite  combinations.  Tool  availability  is  likely  to 
influence  the  design  choices. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification. 

•  Preliminary  conceptual  model  design. 

•  Preliminary  conceptual  model. 

•  Existing  conceptual  models. 

•  Literature  on  views. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  the  preliminary  conceptual 
model  design. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  At  least  one  view  has  been  selected  and  recorded  to  the 
preliminary  conceptual  model  design. 
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Table  G-20:  Conceptual  Model  Process  Activity  4.5  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA4.5  -  Select  a  Notation  Suitable  to  Express  the  Chosen 
Formalism. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  to  select  a  notation  to  express  the 
conceptual  primitives,  model  kinds,  views  and  formalisms. 

This  activity  is  necessary  to  be  intentionally  selective  on  the 
notation  options.  This  activity  is  an  investment  against  the  risk 
of  uninformed  use  of  notations. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consist  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability:  May  begin  when  PA2.3  has  substantial 
progress;  P2.1  -  Conceptual  Model  Requirement  Specification 
has  valuable  input. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Analyze  the  preliminary  conceptual  model  design  to  identify 
which  conceptual  primitives,  model  kinds  and  formalisms 
must  be  supported  by  the  notation. 

•  Survey  notations  options  either  from  the  literature  or  from 
experience. 

•  Make  an  elective  choice  of  notations(s)  in  accordance  with 
the  conceptual  model  characteristics  from  P2.1  -  Conceptual 
Model  Requirement  Specification. 

•  Record  or  update  the  selected  notation(s)  in  the  preliminary 
conceptual  model  design  artefact. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Executed  at  least  once  and  may  be  executed  iteratively  after  new 
inputs  to  the  preliminary  conceptual  model  design  during  PA4.1, 
PA4.2  or  PA4.3  or  after  the  failure  to  meet  the  conceptual  model 
requirements  during  PA4.6  evaluation  or  after  the  addition  of 
requirements  in  P2.1  from  either  some  build  experience  in 

PA5.1,  the  arrival  of  new  stakeholders,  the  evolution  to  different 
conceptual  model  characteristics  (quality,  utility,  formality, 
abstractness),  etc. 
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•  Process  Activity  Information  Flow 

Information  from  P2.1  -  Conceptual  Model  Requirement 
Specification  and  from  external  information  pools  flows  into 
this  activity.  Information  from  this  activity  flows  into  the 
preliminary  conceptual  model  design  and  eventually  into 

P4.1  -  Conceptual  Model  Design. 

Associated  Entities 

•  Tools 

Specific  modeling  tools  can  help  to  select  coherent  conceptual 
model  composite  combinations.  Tool  availability  is  likely  to 
influence  the  design  choices. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification. 

•  Preliminary  conceptual  model  design. 

•  Preliminary  conceptual  model. 

•  Existing  conceptual  models. 

•  Literature  on  views. 

•  Product  /  Object  /  Artefacts 

This  Process  Activity  contributes  to  a  preliminary  conceptual 
model  design. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  At  least  one  notation  has  been  selected  and  recorded  to  the 
preliminary  conceptual  model  design. 

Table  G-21:  Conceptual  Model  Process  Activity  4.6  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 

Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA4.6  -  Evaluate  Design  for  Adequacy/Relevance  with  Respect 
to  Requirements. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

This  activity  is  necessary  for  verifying  whether  conceptual 
model  requirements  have  been  met  by  the  conceptual  model 
design. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  P2.1  -  Conceptual  Model  Requirement  Specification. 
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•  Entrance  Criteria  (cont’d) 

•  The  preliminary  conceptual  model  design. 

•  The  V&V  argumentation  framework. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY  ACTIVITY 
establish  the  context  within  which  the  bulk  of  direct  conceptual 
model  population  will  occur: 

•  Parse  P2.1  -  Conceptual  Model  Requirement  Specification 
to  become  acquainted  with  what  design  characteristics  are 
required. 

•  Parse  the  Preliminary  conceptual  model  Design  and  check 
whether  all  conceptual  model  compositions  have  been 
identified. 

•  Part  of  the  V&V  argumentation  framework  is  concerned 
with  the  quality  of  the  design  of  the  conceptual  model.  These 
topics  must  be  specified  and  transformed  into  design  quality 
criteria,  such  as  whether  all  views  needed  by  the 
stakeholders  are  available  or  whether  the  chosen  formalism 
is  capable  of  expressing  the  conceptual  model. 

•  For  each  design  quality  criterion,  evidence  must  be  obtained. 

•  Finally,  update  the  design  characteristics  in  the  conceptual 
model  data  and  publish  the  conceptual  model  design. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and 
Control-Flow 

Perform  after  the  PA4.1  -  PA4.5  activities  have  finished. 

•  Process  Activity  Information  Flow 

Preliminary  design  whether  the  conceptual  model  Design  meets 
the  conceptual  model  requirements  and  accepts  the  conceptual 
model  design. 

Associated  Entities 

•  Tools 

Book  keeping  aids  like  requirements  tools. 

•  Actor- Agents 

Producer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification. 

•  Preliminary  conceptual  model  design. 

•  The  preliminary  conceptual  model. 

•  Product  /  Object  /  Artefacts 

Verified  conceptual  model  design  and  conceptual  model  Meta 
data. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  When  conceptual  model  design  meets  the  conceptual  model 
requirements  and  when  P4.1  is  complete. 
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Table  G-22:  Conceptual  Model  Process  Activity  5.1  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA5.1  -  Populate  the  Conceptual  Model  Using  the  Chosen 
Primitives,  Model  Kinds,  Formalism,  and  Notation. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Given  information  contained  in  P3.1  -  Validated  Knowledge 
and  P4.1  -  Model  Design;  it  is  necessary  to  compile  a 
(DRAFT  or  FINAL)  version  of  the  preliminary  conceptual 
model.  This  process  step  is  critical  to  the  generation  of  the 
Process  Phase  5  final  work-product  P5.1  -  Conceptual  Model 
insofar  as  it  constitutes  the  accumulation,  binding,  and 
permanent  authoritative  documentation  of  the  desired 
complete  and  consistent  conceptual  model  itself,  relevant  to 
the  military  mission  space  intending  to  be  represented  in  the 
pursuant  model  or  simulation,  in  a  preliminary  form,  pending 
articulation  and  confirmation  to  yield  the  final  conceptual 
model  artefact.  The  fundamental  motivation  of  this  process 
step  is  to  capture  in  concrete,  persistent  form  the  entire 
STRUCTURE  and  PROCESS  entailed  in  the  mission  space 
in  detail,  scope,  and  fidelity  appropriate  to  the  intended  use 
of  the  conceptual  model. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  completion  of  the  following 
activities,  availability  of  information  and  establishment  of 
operational  capability: 

•  Completion  of  previous  activities  (namely  Process  Phase 

3  and  Process  Phase  4),  and  availability  in  DRAFT  or 

FINAL  form  of  their  work-products  (i.e.,  P3.1  -  Validated 
Knowledge  and  P4.1  -  Conceptual  Model  Design). 

•  Establishment  of  conceptual  model  drafting  Group. 

•  Planning  of  effort  entailed  in  PP5  Activity. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  PRELIMINARY  or  PREFATORY 

ACTIVITIES  establish  the  context  within  which  the  bulk  of 
direct  conceptual  model  population  will  occur: 

•  Build  strategy  -  Establish  the  style  of  operation  by  the 

Group,  election  of  alternative  design  options  not  otherwise 
bound  by  requirements,  and  establishing  such  stylistic 
conventions  as  may  facilitate  cooperation  and  efficiency 
of  the  Group.  Build  versions  may  be  spiral  so  that  a 
succession  of  products  is  generated  progressively 
converging  on  the  desired  result.  Alternatively, 
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•  Process  Activity  Procedure  (cont’d) 


parallelization  techniques  such  as  partitioning  the  mission 
space,  allocating  model  constructs  (i.e.,  primitives  or 
model  kinds)  to  Group  members  of  the  group  may  be 
convenient. 

•  Notation  -  Establish  election  of  alternative  options  for 
Primitives,  Model  kinds,  Formalisms  and  Notation  which 
may  persist,  consistent  with  P4.1  -  Conceptual  Model 
Design  specified  constraints  may  be  necessary.  These 
determinations  and  such  style  conventions  to  be  shared 
across  the  Group  should  be  established  by  consensus 
before  significant  build  composition  effort  is  begun. 
Checking  the  implications  of  such  determinations  during 
first  spiral  reviews  will  reassure  the  Group  of  the  wisdom 
of  its  choices. 

•  Sufficiency  Criteria  -  Establish  agreement  upon  prefatory 
interpretation  of  sufficiency  criteria  for  the  expected 
product,  cast  in  terms  of  easily  observable  and 
confirmable  product  characteristics  and  evidently 
correlated  to  requirements  specification  elements  will 
provide  insurance  against  shortfalls  in  product  quality  in 
areas  such  as  detail  and  completeness  (scope,  entities, 
entity-attribute  and  entity-relationships)  as  specified. 

•  Tools  -  Select  and  provide  prompt  access  to  sufficient 
Tools  to  the  conceptual  model  population  Group. 

Selection  of  such  tools  should  be  made  carefully  with 
consideration  for:  a)  familiarity  and  competence  of  Group, 
b)  power  to  meet  conceptual  design  capture  and 
specification,  and  c)  facility  to  generate  views  and 
published  data  products  acceptable  to  customer  user 
stakeholders. 

•  Documentation  -  Establish  Product  Document 
management  process  and  information  storage  and  retrieval 
sufficient  to  contain  the  evolving  conceptual  model  work- 
product,  control  of  its  authoritative  configuration  and 
containing  commentary  on  tactical  decisions  -  just  as  is 
prudent  for  requirements  or  code  management  under  other 
circumstances. 

The  following  EXECUTION  ACTIVITIES  constitute  the 
bulk  of  the  conceptual  model  composition  effort  -  to  be 
executed  with  information  contained  in  P3.1  -  Validated 
Knowledge,  in  accordance  with  the  constraints  manifest  in 
P4.1  -  Conceptual  Model  Design,  commensurate  with  the 
build  strategy  and  manifesting  the  notational  conventions 
previously  agreed-upon: 

•  Designate  object  entities. 
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•  Process  Activity  Procedure  (cont’d) 

•  Designate  entity  class  abstractions. 

•  Designate  entity  class  or  entity  object  attributes  or 
predicates. 

•  Designate  entity  class  and  entity  object  methods  or 
operational  processes. 

•  Designate  static  relationships  among  object  entities  and 
object  classes  including  typically  inheritance 

(e.g.,  specialization-abstraction),  logical  (e.g.,  causal), 
process  subordination  or  composition  and  structural 
composition  relationships. 

•  Designate  dynamic  relationships  associated  with  object 
entities  and  classes,  including  typically  state  transition, 
event  trace,  information  flow  and  interface,  and  activity 
control  relationships. 

Please  NOTE  that  the  enumeration  of  activity  elements  cited 
above  is  not  guaranteed  to  be  complete  or  fully  systematic, 
notwithstanding  its  being  characteristic  of  guidance  provided 
in  respected  literature  and  commonly  observed  in  practice. 

It  should,  in  its  entirety,  however,  provide  procedurally 
concrete  guidance  to  the  conceptual  model  population 
practitioner  In  addition,  the  vernacular  used  in  the  operational 
guidance,  while  somewhat  particular,  should  not  be 
interpreted  as  limiting  or  constraining  in  any  way  the 
determinations  made  a  priori  regarding  “Primitives,  Model 
kinds,  Formalisms  and  Notation  “  Instead,  they  should  be 
considered  a  good  faith  attempt  to  indicate  in  unbiased  form 
the  effort-elements  recommended  to  capture  a  reasonable 
preliminary  conceptual  model  population. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and  Control- 
Flow 

Process  Build  Strategy  -  <see  above>. 

Process  Step  Iteration  -  <see  above>. 

Process  Step  Parallelization  -  <see  above>. 

•  Process  Activity  Information  Flow 

Contingent  guidance  on  Process  Activity  sequence  and 
control  flow  above,  the  following  guidance  is  provided: 

•  Collaboration  -  During  execution,  conduct  of  Group 
reviews  of  work  progress,  product  convergence  according 
to  build  strategies,  and  product  quality  should  compliment 
normal  program  reviews  and  control  mechanisms. 
Cultivation  of  consistency  of  vision  across  the  conceptual 
model  build  Group  is  a  powerful  mechanism  to  maintain 
consistency  of  product,  and  collaboration  among  Group 
members. 

•  Upstream  -  Knowledge/Design  providers,  Stakeholders  - 
essential  to  compliance. 
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•  Process  Activity  Information  Flow 
(cont’d) 

•  Within  activities  -  Population  Group  cohort . . .  essential 
to  convergence  and  consistency  of  product. 

•  To  product  -  Preliminary  conceptual  model  as  official 
record  of  original  entry. . .  essential  to  closure. 

Associated  Entities 

•  Tools 

Notational  Standards  -  Information  and  notational  standards 
assets  likely  to  support  the  subject  activity  include,  for: 

•  Process-Perspective: 

•  IDEF  0. 

•  Petri  Net. 

• 

•  Object-Perspective: 

•  UML. 

•  SYSML. 

•  IDEF -4. 

•  Resource  Description  Frameworks  (XML/RDF/RDFS). 

•  Meta  Object  Facility  (MOF)  Core  Specification  -  OMG 
adopted  specification. 

• 

•  Data/Knowledge/Information-Perspective : 

•  IDEF-  1,  lxKnowledge  Interchange  Format  (KIF). 

•  Open  knowledge  Base  Connectivity  Protocol. 

•  Knowledge  Representation  System  (KRS). 

•  SQL. 

•  Entity  Relationship  Model  (ERM). . . 

• 

•  Ontology  Perspective: 

•  ISO/IEC  1350  Topic  Maps. 

•  OWL. 

•  IDEF  5. 

•  Ontology  Interface  Layer  (OIL). 

•  Ontology  Exchange  Language  (OXL). 

•  Ontolingua. 

• 

COTS  CASE  Tools  -  Software  assets  likely  to  support  the 
subject  activity  are  available  from  within  the  assets  of  four 
coexisting  communities  of  practice  as  follows: 
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•  Tools  (cont’d) 


•  Systems  Engineering/ Architecture  -  Typical,  but  not 
necessarily  recommended  tools  in  this  category  are: 

•  Systems  Architect. 

•  Microsoft  Visio. 

•  Cradle. 

•  CORE. 


•  Software  development  -  Typical,  but  not  necessarily 
recommended  tools  in  this  category  are: 

•  IBM  Rational  Software  Modeler  (formerly  Rational 
Rose). 

•  Microsoft  Visio. 


•  Data  Engineering  -  Typical,  but  not  necessarily 
recommended  tools  in  this  category  are: 

•  Myriad  DBMS  assets. 

• 

•  Ontology  and  Knowledge  Analysis  -  Typical,  but  not 
necessarily  recommended  tools  in  this  category  are: 

•  Apollo. 

•  LinkFactory. 

•  OILdOntoEdit. 

•  Ontolingua  Server. 

•  OpenKnoME. 

•  Protege  -  2000. 

•  SymOntoXWebODE. 

•  WebOntoChimera. 

•  FCA-Merge. 

•  PROMPT. 

•  ODEMerge. 


NOTE  that  suitability  of  tools  is  strongly  contingent  upon  the 
a  priori  selection  of  Primitives,  Model  kinds,  Formalisms  and 
Notation  cited  above.  In  particular,  tools  are  invariably 
notation  specific;  but  their  having  implicit  capability  or  bias 
toward  one  or  another  set  of  object-  versus  process-  versus 
data-orientation  and  choice  of  primitives  is  significant  and 
should  not  be  overlooked. 
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•  Actor- Agents 

Agents  populating  the  preliminary  conceptual  model  are 
typically  individuals  or  a  designated  Group  specifically  familiar 
with  the  required  activities  and  expected  consequential 
products.  Execution  -  implementation  agents  must  be  familiar 
with  a  range  of  optional  approaches,  competent  to  execute  the 
designated  procedures,  and  competent  to  collaborate  with  other 
stakeholder  role  holders  to  ensure  that  the  process  executed  and 
product  generated  are  acceptable  for  intended  use  of  the 
prospective  conceptual  model. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include  input  data 
artefacts  and  preliminary  conceptual  model  product  in  whole 
or  in  part  pursuant  to  the  completion  of  the  subject  activity. 

In  addition,  it  is  likely  that  a  variety  of  intermediate  information 
pools  will  be  generated  as  Group  member  contributions  are 
generated  or  partial  activity  results  components  are  generated 
in  anticipation  of  compilation  of  these  elements  in  the 

DRAFT  preliminary  conceptual  model  work-product. 

•  Product  /  Object  /  Artefacts 

The  principle  desired  output  of  the  subject  activity  is  the 
preliminary  conceptual  model.  This  product  is  described  in 
Annex  F. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Execution  all  process  steps  indicated  above. 

•  Generation  of  a  preliminary  conceptual  model,  including 
intentional  bindings  of  Primitives,  Model  kinds, 

Formalisms  and  Notation;  according  to  an  unambiguously 
specified  notational  formalism;  with  the  following 
attributes: 

•  Completeness: 

•  Preliminary  conceptual  model  shall  exhaust  in  scope 
of  its  contents  the  description  of  mission-space  and 
simulation-space  domains. 

•  The  model  shall  contain  all  the  expository  features 
entailed  in  the  notational  schema  (as  tailored)  that 
is  used  in  the  capture  of  the  model  documentation. 

•  Consistency: 

•  Preliminary  conceptual  model  shall  exhibit 
commensurate  detail  among  its  respective  conceptual 
model  components. 

•  Expression  of  the  preliminary  conceptual  model  shall 
be  expressed  systematically  in  accord  with 

the  notational  schema  of  chosen  tools  and 
representational  notations. 
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•  Exit  Criteria  (cont’d) 

•  Correctness: 

•  Preliminary  conceptual  model  contents  shall  be 
plausibly  correct  in  providing  representations  of 
mission-space  and  simulation  space  domains, 
contingent  execution  of  VV&A  and  further  credibility 
determinations  and  findings  to  be  achieved  in 
following  activities. 

•  Sufficiency: 

•  Preliminary  conceptual  model  shall  be  plausibly 
sufficient  for  its  intended  use  by  each  of  several 
stakeholders  committed  to  the  subject  enterprise. 

Criteria  reference  “values”  for  demonstration  of  satisfactory 
completion  of  the  subject  activity  -  insofar  as  they  shall  be 
needed  in  addition  to  the  specific  guidance  above  -  shall  be 
established  by  the  conceptual  model  development  Group  and 
made  a  matter  of  explicit  record  in  anticipation  of  the  subject 
completion  evaluation. 

Table  G-23:  Conceptual  Model  Process  Activity  5.2  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA5.2  -  Create  the  Specified  Views. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Given  information  contained  in  the  result  of  activity  PA5.1, 
e.g.,  the  preliminary  conceptual  model;  it  is  necessary  to 
elaborate  that  model  by  establishing  the  set  of  canonical 
‘views’  or  perspective  of  that  preliminary  conceptual  model 
so  that  that  model’s  contents  may  be  precisely  and  thoroughly 
appreciated  by  the  stakeholder  community  and  in  particular 
so  the  it  may  be  systematically  appreciated  and  understood 
consistently  by  the  members  of  the  P5.1  -  Conceptual  Model 
product  development  Group  for  purposes  of  execution  of 
activities  PA5.2  -  PA5.4.  Consistent  appreciation  of  the 
content  and  significances  of  the  syntax  and  semantics  of  the 
Preliminary  conceptual  model  by  all  members  of  the 
conceptual  model  development  Group  is  essential  to  the 
convergence  of  the  preliminary  model  to  the  final  conceptual 
model  artefact. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 
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•  Entrance  Criteria  (cont’d) 

•  Completion  of  the  Preliminary  conceptual  model  to  the 
degree  that  its  stability,  scope  and  relevance  are  evident, 
prime  facie,  to  the  conceptual  model  development  Group. 

•  Documentation  of  the  notational  schema  whereby  the 
Preliminary  Conceptual  model  has  been  compiled,  and 
publication  of  tools  and  associated  data  interchange 
schemas  known  readily  to  be  available  for  operating  upon 
the  contents  of  the  preliminary  conceptual  model. 

•  Designation  of  the  conceptual  model  views  generation 
and  publication  work  cadre. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  following  activities  constitute  the  process  whereby  the 
establishment  of  views  reflecting  the  contents  of  the 

Preliminary  conceptual  model  shall  be  made  manifest: 

•  Strategy  -  Establish  systematic  strategy  and  procedures 
for  educing  and  publishing  views  from  the  Preliminary 
Conceptual  Mode. 

•  View  Inventory  -  Select  views  to  be  employed  in 
depicting  the  preliminary  Conceptual  model.  Such  views 
should  be  assured  to  support  the  interests  of  enterprise 
stakeholders,  but  particularly  the  following:  a)  VV&A 
agents,  b)  Customers  and  users  of  the  information 
contained  in  the  conceptual  model,  and  particularly, 

c)  developers  of  the  intended  objective  simulation  system 
These  determinations  and  such  style  conventions  to  be 
shared  across  the  Group  should  be  established  by 
consensus  before  significant  build  composition  effort  is 
begun.  Checking  the  implications  of  such  determinations 
during  first  spiral  reviews  will  reassure  the  Group  of  the 
wisdom  of  its  choices. 

•  Sufficiency  Criteria  -  Establish  agreement  upon  prefatory 
interpretation  of  sufficiency  criteria  for  the  expected 
product,  cast  in  terms  of  easily  observable  and 
confirmable  product  characteristics  and  evidently 
correlated  to  requirements  specification  elements  will 
provide  insurance  against  shortfalls  in  product  quality  in 
areas  such  as  detail  and  completeness  (scope,  entities, 
entity-attribute  and  entity-relationships)  as  specified. 

•  Tools  -  Select  and  provide  prompt  access  to  sufficient 

Tools  to  the  conceptual  model  view  generation  Group. 
Selection  of  such  tools  should  be  made  carefully  with 
consideration  for:  a)  familiarity  and  competence  of 

Group,  b)  power  to  meet  conceptual  design  capture  and 
specification,  and  c)  facility  to  generate  views  and 
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•  Process  Activity  Procedure  (cont’d) 


published  data  products  acceptable  to  customer  user 
stakeholders. 

Documentation  -  establish  Product  Document  management 
process  and  information  storage  and  retrieval  sufficient  to 
contain  the  evolving  conceptual  model  view-set  work-product, 
control  of  its  authoritative  configuration  and  containing 
commentary  on  tactical  decisions  -  just  as  is  prudent  for 
requirements  or  code  management  under  other  circumstance. 
The  following  EXECUTION  ACTIVITIES  constitute  the 
bulk  of  the  conceptual  model  view  generation  effort  -  to  be 
executed  consonant  with  information  contained  in  the 
preliminary  conceptual  model,  commensurate  with  the  build 
strategy,  and  manifesting  the  notational  conventions 
previously  agreed-upon: 

•  Elect  one  of  the  (possibly)  several  view  types  identified 
for  this  activity. 

•  Using  the  preliminary  conceptual  model  as  a  basis  for 
interpretation  and  representation,  generate  view 
components  consistent  with  the  view  type  being 
addressed,  covering  the  entire  scope  of  the  Preliminary 
Conceptual  model  and  preserving  detail  contained  in  the 
preliminary  conceptual  model  in  so  far  as  the  subject  view 
allows.  Integrate  view  elements  by  means  of  composition, 
or  generalization  relationships  insofar  as  the  subject  view 
schema  allows. 

•  Select  another  of  the  intended  representation  views  and 
repeat  as  above.  When  one  pass  implementing  all  desired 
views  are  completed  proceed  to  next  step  following. 

•  Conduct  systematic  cross-reference  of  view  consistency 
by  means  suitable  to  ensure  that  all  vies  represent/reflect/ 
reveal  the  Preliminary  conceptual  model  consistently  and 
comprehensively.  Such  cross-reference  techniques  as  are 
deemed  suitable  by  the  conceptual  model  views 
generation  Group  are  acceptable,  but  the  following  are 
particularly  endorsed:  a)  thorough  reconciliation  of 
representative  use  case  in  mission  space  and  simulation 
space  domains,  b)  reconciliation  of  views  for  any  such 
components  of  the  Preliminary  conceptual  model  as  may 
be  perceived  to  have  unusually  close  coupling  in  object 
or  process  terms,  c)  reconciliation  of  views  for  parts  of 
preliminary  conceptual  model  as  may  be  considered 
particularly  significant;  that  is:  those  which  were 
unusually  difficult  to  generate  originally,  those  which  are 
perceived  to  be  particularly  difficult  to  understand, 

and  those  that  are  perceived  to  be  particularly  relevant  to 
one  or  another  stakeholder. 
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•  Process  Activity  Procedure  (cont’d) 

•  Document  all  views  generated  with  qualifying 
commentary  regarding  their  significance,  their 
relationships,  and  the  use  of  notational  conventions  with 
which  they  have  been  conceived  and  published. 

Please  NOTE  that  the  enumeration  of  activity  elements  cited 
above  is  not  guaranteed  to  be  complete  or  fully  systematic, 
notwithstanding  its  being  characteristic  of  guidance  provided 
in  respected  literature  and  commonly  observed  in  practice. 

It  should,  in  its  entirety,  however,  provide  procedurally  concrete 
guidance  to  the  conceptual  model  population  practitioner. 

In  addition,  the  vernacular  used  in  the  operational  guidance, 
while  somewhat  particular,  should  not  be  interpreted  as 
limiting  or  constraining  in  any  way  the  determinations  made 
a  priori  regarding  Conceptual  model  views.  Instead,  they 
should  be  considered  a  good  faith  attempt  to  indicate  in 
unbiased  form  the  effort-elements  recommended  to  disclose 
a  reasonable  preliminary  conceptual  model  population. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and  Control- 
Flow 

Process  Build  Strategy  -  <see  above>. 

Process  Step  Iteration  -  <see  above>. 

Process  Step  Parallelization  -  <see  above>. 

•  Process  Activity  Information  Flow 

Contingent  guidance  on  Process  Activity  sequence  and  control 
flow  above,  the  following  guidance  is  provided: 

•  Collaboration  -  During  execution,  conduct  of  Group 
reviews  of  work  progress,  product  convergence  according 
to  build  strategies,  and  product  quality  should  compliment 
normal  program  reviews  and  control  mechanisms. 
Cultivation  of  consistency  of  vision  across  the  conceptual 
model  build  Group  is  a  powerful  mechanism  to  maintain 
consistency  of  product,  and  collaboration  among  Group 
members. 

•  Upstream  -  Knowledge/Design  providers,  Stakeholders  - 
essential  to  compliance. 

•  Within  activities  -  Population  Group  cohort  . . .  essential 
to  convergence  and  consistency  of  product. 

•  To  product  -  Preliminary  conceptual  model  as  official 
record  of  original  entry  . . .  essential  to  closure. 

Associated  Entities 

•  Tools 

See  discussion  of  standards  and  COTS/CASE  tools  provided 
in  exposition  of  process  step  5.1  above. 

•  Actor- Agents 

Agents  producing  views  of  the  preliminary  conceptual  model 
are  typically  individuals  or  a  designated  Group  specifically 
familiar  with  the  required  activities  and  expected 
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•  Actor- Agents  (cont’d) 

consequential  products.  Execution  -  implementation  agents 
must  be  familiar  with  a  range  of  optional  approaches, 
competent  to  execute  the  designated  procedures,  and 
competent  to  collaborate  with  other  stakeholder  role  holders 
to  ensure  that  the  process  executed  and  product  generated  are 
acceptable  for  intended  use  of  the  prospective  conceptual 
model. 

Merit  exists  in  choosing  views  generation  agents  from  the 
preliminary  development  Group  and  from  among  stakeholders 
associated  with  prospective  conceptual  model  verification, 
validation  and  use,  in  order  to  assure  that  the  most  consistent, 
intelligible  and  potentially  useful  suite  of  conceptual  model 
views  is  generated  by  consensus  among  disparate  stakeholder 
communities. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include  input  data 
artefacts  and  preliminary  conceptual  model  product  in  whole 
or  in  part  pursuant  to  the  completion  of  the  subject  activity. 

In  addition,  it  is  likely  that  a  variety  of  intermediate  information 
pools  will  be  generated  as  Group  member  contributions  are 
generated  or  partial  activity  results  components  are  generated 
in  anticipation  of  compilation  of  these  elements  in  the  DRAFT 
preliminary  conceptual  model  work-product. 

•  Product  /  Object  /  Artefacts 

The  principle  desired  output  of  the  subject  activity  is  the  suite 
of  expository  views  of  the  preliminary  conceptual  model. 

This  product  is  described  in  Annex  F. 

Process  Activity  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Execution  all  process  steps  indicated  above. 

•  Generation  of  an  ensemble  of  views  for  the  subject 
preliminary  conceptual  model,  according  to  an 
unambiguously  specified  notational  formalism;  with  the 
following  attributes: 

•  Completeness: 

•  Preliminary  conceptual  model  views  shall  exhaust  in 
scope  of  its  contents  the  description 

of  mission-space  and  simulation- space  domains. 

•  The  model  views  shall  contain  all  the  expository 
features  entailed  in  the  notational  schema 

(as  tailored)  that  is  used  in  the  capture  of  the  model 
documentation. 
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•  Exit  Criteria  (cont’d) 

•  Consistency: 

•  Preliminary  conceptual  model  views  shall  exhibit 
commensurate  detail  among  its  respective  conceptual 
model  components. 

•  Expression  of  the  preliminary  conceptual  model  views 
shall  be  expressed  systematically  in  accord  with  the 
notational  schema  of  chosen  tools  and  representational 
notations. 

•  Correctness: 

•  Preliminary  conceptual  model  view  contents  shall  be 
plausibly  correct  in  providing  representations  of 
mission-space  and  simulation  space  domains, 
contingent  execution  of  VV&A  and  further  credibility 
determinations  and  findings  to  be  achieved  in 
following  activities. 

•  Sufficiency: 

•  Preliminary  conceptual  model  views  shall  be  plausibly 
sufficient  for  its  intended  use  by  each  of  several 
stakeholders  committed  to  the  subject  enterprise. 

Criteria  reference  “values”  for  demonstration  of  satisfactory 
completion  of  the  subject  activity  -  insofar  as  they  shall  be 
needed  in  addition  to  the  specific  guidance  above  -  shall  be 
established  by  the  Conceptual  Model  development  Group  and 
made  a  matter  of  explicit  record  in  anticipation  of  the  subject 
completion  evaluation. 

Table  G-24:  Conceptual  Model  Process  Activity  5.3  Description. 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA5.3  -  Verify  Conceptual  Model  Consistency  with  Respect 
to  Conceptual  Model  Design. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Given  information  contained  in  the  result  of  activity  PA5.1, 
e.g.,  the  preliminary  conceptual  model;  it  is  necessary  to 
establish  the  credibility  and  user  confidence  appropriate  to  be 
held  in  the  preliminary  conceptual  model.  On  this  account,  two 
steps  are  warranted:  verification  of  the  preliminary  model  in 
comparison  to  the  conceptual  model  Design  (Product  P4.1) 
and,  subsequently,  the  validation  of  the  preliminary  model  in 
comparison  to  the  validated  knowledge  manifest  of  the 
simulation  representation  and  simulation  execution  domains 
as  Product  P3.1.  This  section  addresses  the  former  effort. 
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Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  Completion  of  the  Preliminary  conceptual  model  and  its 
associated  views  heretofore  incorporated,  to  the  degree 
that  its  credibility  and  commensurability  to  the  Conceptual 
Model  Design  are  evident,  prime  facie,  to  the  conceptual 
model  development  group. 

•  Documentation  of  the  verification  plan  whereby  the 
preliminary  conceptual  model  is  to  be  evaluated,  this  plan 
should  contain  strategies,  and  procedures  whereby  the 
congruity  of  the  preliminary  conceptual  model  and  the 
antecedent  Conceptual  Model  Design  is  to  be  demonstrated. 

•  Designation  of  the  Conceptual  Model  verification 
evaluation  and  publication  work  cadre. 

Process  Activity  Method 

•  Process  Activity  Procedure 

The  fundamental  nature  of  verification  of  a  subject  artefact 
(here,  the  preliminary  Conceptual  Model)  to  a  referent 
information  source  (here,  the  content  of  the  P4.1  -  Conceptual 
Model  Design),  entails  corroboration  of  conformance  of  the 
former  in  its  structure,  attributes  and  (functionality)  to  the 
informational  content  of  the  latter. 

Procedural  guidance  for  verification  execution  is  highly 
contingent  upon  the  nature  of  the  subject,  the  referent,  and  the 
intended  use  of  the  subject  for  which  verification  confirmation 
is  desired.  On  that  count,  no  more  than  provisional  guidance 
can  be  provided  here  to  guide  verification  execution  toward 
successful  conclusion.  In  fact,  however,  there  exists  a  copious 
literature  whereby  such  verification  may  be  conducted. 

In  view  of  the  specialization  of  VV&A  necessary  for  any 
particular  conceptual  model  evaluation,  and  the  myriad  of 
techniques  for  that  purpose  available  in  National,  and 
international  ‘best-practice’  guidance  (e.g.,  HLA,  NATO); 

Only  precepts,  strategic  guidance  and  cautionary  instructions 
are  provided  in  the  procedural  entries  that  follow: 

•  Publish  and  execute  a  conceptual  model  verification  plan, 
including  specification  of:  a)  verification  needs,  b) 
requirements,  c)  activities,  d)  data  products,  e)  necessary 
and  sufficient  resources,  f)  management,  and  g)  work- 
product. 

•  Show  rationale  whereby  planned  verification  effort 
devolves  and  satisfies  to  a  sufficient  degree  the  intention 
of  verification,  itself  predicated  upon  appreciation  of  the 
intended  use  of  the  conceptual  model. 
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•  Process  Activity  Procedure  (cont’d) 

•  Particularly  link  verification  effort  to  the  demonstration 
of  suitable  compliance  of  the  preliminary  conceptual 
model  to  the  Conceptual  Model  Design  manifest  in  the 
work-product  P4. 1 . 

•  Establish  clearly  defined  verification  evaluation 
components  and  criteria  for  satisfaction  of  verification 
evaluation  component  activities. 

•  Report  results  of  verification  effort  in  accordance  with 
description  of  the  Accreditation  Report  element  of 
conceptual  model  work  produce  specified  in  Annex  F. 

•  Coordinate  verification  plan  and  results  with  significant 
stakeholders. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and  Control- 
Flow 

Process  Build  Strategy  -  <see  above>. 

Process  Step  Iteration  -  <see  above>. 

Process  Step  Parallelization  -  <see  above>. 

•  Process  Activity  Information  Flow 

Contingent  guidance  on  Process  Activity  sequence  and  control 
flow  above,  the  following  guidance  is  provided: 

•  Collaboration  -  During  execution,  conduct  of  Group 
reviews  of  work  progress,  product  convergence  according 
to  build  strategies,  and  product  quality  should  compliment 
normal  program  reviews  and  control  mechanisms. 
Cultivation  of  consistency  of  vision  across  the  Conceptual 
Model  Build  Group  is  a  powerful  mechanism  to  maintain 
consistency  of  product,  and  collaboration  among  Group 
members. 

•  Upstream  -  Input  from  Conceptual  Model  Design  product 
and  product-providers,  Stakeholders  -  essential  to 
compliance. 

•  Within  activities  -  Population  Group  cohort . . .  essential 
to  convergence  and  consistency  of  product. 

•  To  product  -  Preliminary  conceptual  model  or  to 

Conceptual  Model  Verification  Report  as  official  record 
of  original  entry  is  essential  to  closure. 

Associated  Entities 

•  Tools 

See  discussion  of  standards  and  COTS/CASE  tools  provided 
in  exposition  of  process  step  5.1  above. 

•  Actor- Agents 

V&V  Agents. 

•  Information  Pools 

P4.1  -  Conceptual  Model  Design  documentation,  together 
with  Preliminary  conceptual  model  artefact  are  information 
necessary  and  sufficient  to  support  the  completion  of  this 
activity. 
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•  Product  /  Object  /  Artefacts 

While  no  formal  work-product  is  indicated  in  the  process 
model  as  consequent  the  execution  of  this  activity,  it  is 
recommended  that  a  certificate  of  verification  be  produced  and 
made  a  part  of  the  formal  documentary  conceptual  model  data 
package  for  reference  in  subsequent  VV&A  efforts  and  for 
reference  within  the  enterprise  environment. 

Process  Activity  Completion 

•  Exit  Criteria 

Determination  of  the  adequacy  of  verification  of  the 
conceptual  model  with  regard  to  consistency  with  conceptual 
model  design  and  generation  of  an  authoritative,  permanent, 
accessible  record  of  such  verification. 

Table  G-25:  Conceptual  Model  Process  Activity  5.4  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA5.4  -  Validate  Conceptual  Model  with  Respect  to  Mission 
Space  and  Simulation  Space  Knowledge. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Given  information  contained  in  the  result  of  activity  PA5.1, 
e.g.,  the  preliminary  conceptual  model;  it  is  necessary  to 
establish  the  credibility  and  user  confidence  appropriate  to  be 
held  in  the  preliminary  conceptual  model.  On  this  account,  two 
steps  are  warranted:  verification  of  the  preliminary  model  in 
comparison  to  the  conceptual  model  Design  (Product  P4.1), 
and,  subsequently,  the  validation  of  the  preliminary  model  in 
comparison  to  the  validated  knowledge  manifest  of  the 
simulation  representation  and  simulation  execution  domains 
as  Product  P3.1.  This  section  addresses  the  latter  effort. 

Process  Activity  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  achievement  of  the  following 
state: 

•  Tasks  PA5.1  -  5.3  are  complete. 

•  Product  P3.1  is  available. 

•  Preliminary  conceptual  model  DRAFT  is  available  for 
evaluation. 

Process  Activity  Method 

•  Process  Activity  Procedure 

Execution  agent  conducts  following  activity: 

•  Establish  rational  for  validation  criteria. 

•  Specify  validation  criterion  sufficiency  levels  based  on 
state  of  mission  and  simulation  space  knowledge. 
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•  Process  Activity  Procedure  (cont’d) 

•  Evaluate  preliminary  conceptual  model  attributes. 

•  Compare  attributes  as  evaluated  to  the  criterion  values 
previously  established. 

•  Document  compliance  or  minimal  sufficiency  of  attributes 
of  the  preliminary  conceptual  model  in  relation  to 
reference  values. 

•  Revise  conceptual  model  (or  reconsider  mission  space  and 
simulation  space  knowledge  formulation  and/or  contents). 

•  Repeat  evaluation  step  until  sufficiency  achieved. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and  Control- 
Flow 

This  activity  follows  Activity  PA5.3  and  subsequent 
determination  of  adequacy  of  the  results  of  that  activity. 

It  precedes  Activity  PA5.6. 

•  Process  Activity  Information  Flow 

Activity  uses  information  from  Product  P3.1  -  Validated 
Knowledge  and  provides  information  to  the  preliminary 
conceptual  model. 

Associated  Entities 

•  Tools 

VV&A  tools  chosen  for  use  within  the  enterprise. 

•  Actor- Agents 

V&V  agent. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include  the 
preliminary  conceptual  model  and  P3.1  -  Validated 

Knowledge. 

•  Product  /  Object  /  Artefacts 

None. 

Process  Activity  Completion 

•  Exit  Criteria 

Complete  demonstration  of  satisfaction  of  attributes  of  the 
preliminary  conceptual  model  to  criteria  derived  from. 

Table  G-26:  Conceptual  Model  Process  Activity  5.5  Description 


PROCESS  ACTIVITY  CHARACTERISTIC 


Process  Activity  Identity 

•  Process  Activity  Name  and  Aliases 

PA5.5  -  Ensure  Acceptance  of  Conceptual  Model  by 

Authorized  Stakeholders. 

Process  Activity  Description 

•  Process  Activity  Rationale  /  Need  / 
Motivation 

Satisfaction  of  stakeholders’  needs  in  creation  and  subsequent 
utility  of  conceptual  models  is  the  fundamental  objective  of 
conceptual  model  development  activity.  Confirmation  of 
suitability  of  the  conceptual  model  work-product  with 
stakeholder(s)  authorized  to  render  that  judgement  is  the 
proximate  objective  of  the  effort. 
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Process  Activity  Initiation 

•  Entrance  Criteria 

Completion  of  development  Process  Activities  through  PA5.4 
and  a  FINAL  DRAFT  of  the  conceptual  model,  together  with 
associated  work-products  are  necessary  pre-conditions  for 
completing  this  activity. 

Process  Activity  Method 

•  Process  Activity  Procedure 

Particular  activities  considered  necessary  and  sufficient  to 
complete  this  process  step  include: 

•  Check  for  completion  of  preceding  efforts  and  entrance 
criteria. 

•  Compile  full  documentation  suite  including  FINAL 

DRAFT  preliminary  conceptual  model. 

•  Identify  authoritative  stakeholder(s)  whose  approval  is 
considered  necessary. 

•  Prepare  decision  briefing. 

•  Prepare  authorization  documentation. 

•  Execute  decision  briefing. 

•  Obtain  authorization  documentation  signature. 

Inter  Process  Activity  Relationships 

•  Process  Activity  Sequence  and  Control- 
Flow 

This  Process  Activity  follows  Activity  PA5.4  and  the 
adequacy  decision  following.  It  is  the  last  step  in  PP5. 

•  Process  Activity  Information  Flow 

Information  flow  into  this  activity  includes  the  FINAL 

DRAFT  preliminary  conceptual  model  as  well  as  any 
necessary  information  from  preceding  information  data 
products  generated  during  the  conceptual  modeling  process 
Output  information  includes  a  formally  approved  conceptual 
model  designated  Product  5.1. 

Associated  Entities 

•  Tools 

No  special  tools  required. 

•  Actor- Agents 

Principal  actor  agents  contributing  in  this  activity  are  the 
conceptual  model  development  effort  program  manager 
(and  associated  administrative  staff)  and  the  designated 
authoritative  Stakeholder(s)  whose  approval  is  solicited. 

•  Information  Pools 

Preliminary  conceptual  model  and  associated  collateral 
documentation. 

•  Product  /  Object  /  Artefacts 

P5.1  -  Approved  Conceptual  Model. 

Process  Activity  Completion 

•  Exit  Criteria 

Approval  of  FINAL  DRAFT  conceptual  model  by 
authoritative  stakeholder(s). 
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Table  H-1:  Generic  Template  for  Specification  of  Product. 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

<Denotative  names  and  identifiers  of  Product  > 

Product  Description 

•  Product  Definition 

<A  definition  of  the  subject  Product.  > 

•  Product  Purpose 

<Describes  the  purpose  of  the  Product,  both  in  the 
development  process  and  as  an  artefact  for  later  reference.  > 

•  Product  Content 

<Describe  the  content  of  the  product  > 

•  Product  Structure/Format 

<Describe  the  structure  of  the  product.  > 

Product  Initiation 

•  Entrance  Criteria 

<This  field  specifies  component  values  that  are  necessary  and 
sufficient  for  the  development  of  subject  Product  to  be 
effectively  initiated.  > 

Product  Development  Guidance 

•  Product  Development 

<In  this  field,  the  agent  is  provided  procedural  guidance  for 
the  development  of  the  subject  Product.  Note  that  relationships 
to  Process  Activities  and  needs  for  tools  or  information  are 
specified  in  other  form  records.  > 

Product  Relationships 

•  Product  -  Process  Relationships 

instruction  regarding  the  Process  steps  and  sub-steps  that 
produce  this  Product,  and  the  Process  steps  and  sub-steps  that 
use  this  Product.  > 

•  Inter-Product  Relationships 

instruction  regarding  the  relationships  between  this  Product 
and  all  other  relevant  Products.  These  instructions  should 
indicate  which  Products  are  predecessors  to  this  Product, 
which  are  successors,  and  which  may  be  done  in 
concurrence.  > 

Associated  Entities 

•  Tools 

identify  tools  such  as  hardware  or  software  necessary  and 
sufficient,  or  useful,  to  complete  the  Product.  > 

•  Actor- Agents 

indicate  the  actor  agents  responsible  for  development  of  the 
Product,  and  their  respective  roles.  > 
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•  Information  Pools 

<Data  stores  of  any  type  containing  information  used  as  input 
or  generated  as  key  content  of  the  Product.  May  contain 
intermediate  information  re-used  by  this  or  successor 

Products,  or  components  of  the  Product  compiled  as  residual 
documentation.  > 

Product  Completion 

•  Exit  Criteria 

<This  field  specifies  component  values  that  are  necessary  and 
sufficient  for  the  subject  Product  to  be  considered  finished.  > 
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Table  H-2:  Conceptual  Model  Product  1.1  Description. 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

Pl.l  -  Stakeholder  Description. 

Product  Description 

•  Product  Definition 

Document  mapping  stakeholders  to  roles  and  responsibilities 
in  the  Conceptual  Model  effort. 

•  Product  Purpose 

The  purpose  of  this  product  is  to  identify  the  stakeholders  of 
this  Conceptual  Model  development  process  and  their 
respective  roles  and  responsibilities  to  enable  staffing/tasking 
of  the  Conceptual  Model  development  effort,  derivation  of 
stakeholder-related  requirements  and  stakeholder-related 
knowledge  needs,  and  identification  of  subject-matter  expertise 
for  knowledge  acquisition. 

•  Product  Content 

Conceptual  model  knowledge  acquisition  needs  shall  describe 
at  a  minimum: 

•  Relevant  Conceptual  Model  development  responsibilities 
identified  and  grouped  into  roles;  and 

•  Stakeholders  identified  organizationally,  mapped  to 
responsibilities  and  roles. 

Desired: 

•  Stakeholder  identities  by  name,  along  with  contact 
information. 

•  Product  Structure/Format 

No  mandated  format. 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  Product  development  may  begin  once  PA1.1  begins. 

Product  Development  Guidance 

•  Product  Development 

See  PAl.l. 

Product  Relationships 

•  Product  -  Process  Relationships 

PA1.1  produces  this  product,  which  is  used  by  PA2.1  and 

PA2.4. 

•  Inter-Product  Relationships 

This  product  may  be  developed  concurrently  with  PI. 2,  PI. 3, 
and  PI. 4,  but  must  be  completed  prior  to  the  completion  of 
products  from  any  later  phases. 

Associated  Entities 

•  Tools 

None  required. 
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•  Actor- Agents 

•  Producer. 

•  Conceptual  Model  Developer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Points  of  contact  lists. 

•  Employee  roles. 

•  Organizational  charts. 

•  Personnel  databases,  referrals,  resumes,  biographies. 

•  Any  intermediate  information  generated  during  execution 
of  PAl.l. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Product  must  contain  comprehensive  list  of  stakeholders 
by  organization  as  a  minimum,  mapped  to  all  related 
requirements  and  roles. 

Table  H-3:  Conceptual  Model  Product  1.2  Description. 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

PI  .2  -  Need  Statement. 

Product  Description 

•  Product  Definition 

Document  that  defines  the  intended  use  of  the  Conceptual 

Model  derived  from  the  purpose  and  intended  use  of  the  M&S 
effort. 

•  Product  Purpose 

This  product  serves  as  the  source  from  which  to  derive  the  set 
of  Conceptual  Model  requirements  and  knowledge  needs 
which  are  driven  by  M&S  purpose  and  intended  use. 

•  Product  Content 

Description  of  Conceptual  Model  intended  use  driven  by  M&S 
purpose  and  intended  use. 

•  Product  Structure/Format 

No  mandated  format. 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  Product  development  may  begin  once  PA1.2  begins. 

Product  Development  Guidance 

•  Product  Development 

See  PA  1.2. 
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Product  Relationships 

•  Product  -  Process  Relationships 

PA1.2  produces  this  product,  which  is  used  by  PA2.1,  PA2.2, 
and  PA2.4. 

•  Inter-Product  Relationships 

This  product  may  be  developed  concurrently  with  Pl.l,  PI. 3, 
and  PI. 4,  but  must  be  completed  prior  to  the  completion  of 
products  from  any  later  phases. 

Associated  Entities 

•  Tools 

Requirements  Management  tools  optional. 

•  Actor- Agents 

•  Producer. 

•  Conceptual  Model  Developer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Task  orders. 

•  Mission  needs  statements. 

•  M&S  needs  statements. 

•  User  requirement  documents. 

•  Requests  for  proposal. 

•  Statements  of  work. 

•  Formal  or  informal  directives. 

•  Test  agreements. 

•  Any  intermediate  information  generated  during  execution 
ofPA1.2. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Product  must  contain  comprehensive  description  of 
Conceptual  Model  intended  use  sufficient  to  drive  all 
Conceptual  Model  requirements  and  knowledge  needs 
related  to  purpose  and  intended  use  of  M&S. 

Table  H-4:  Conceptual  Model  Product  1.3  Description 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

PI. 3  -  Constraints  and  Policies. 

Product  Description 

•  Product  Definition 

Document  that  defines  the  constraints  and  policies  to  be 
applied  to  the  Conceptual  Model  effort  based  upon  initial 
direction  and  enterprise  scope. 
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•  Product  Purpose 

This  product  serves  as  a  set  of  constraints  upon  the  Conceptual 
Model  requirements  and  knowledge  needs  and  impacts  the 
content  of  Conceptual  Model  requirements  and  knowledge 
needs  which  are  driven  by  constraints  and  policies. 

•  Product  Content 

List  of  constraints  and  mandates  affecting  the  Conceptual 

Model  development  and  design. 

•  Product  Structure/Format 

No  mandated  format. 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  Product  development  may  begin  once  PA1.3  or  PA1.4 
begins. 

Product  Development  Guidance 

•  Product  Development 

Execute  PA  1.3  and  PA  1.4  concurrently  or  in  any  order. 

Product  Relationships 

•  Product  -  Process  Relationships 

PAl  .3  and  PA1 .4  produce  this  product,  which  is  used  by 

PA2.1,  PA2.2,  and  PA2.4. 

•  Inter-Product  Relationships 

This  product  may  be  developed  concurrently  with  PI.  1,  PI. 2, 
and  PI  .4,  but  must  be  completed  prior  to  the  completion  of 
products  from  any  later  phases. 

Associated  Entities 

•  Tools 

None. 

•  Actor- Agents 

•  Producer. 

•  Conceptual  Model  Developer. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Enterprise  standard  operating  procedures. 

•  Industry  and  government  standards. 

•  Enterprise  executive  mandates,  law. 

•  Agency  regulations. 

•  Agency  directives. 

•  Written  policy. 

•  Implied  enterprise  mandates. 

•  Documented  resource  constraints. 

•  Senior  stakeholder  preferences  and  requirements. 

•  Planning/budgeting/management  limitations. 

•  Legacy  M&S  preferences  and  availability. 

•  Data  availability. 
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•  Information  Pools  (cont’d) 

•  Enterprise  preferences. 

•  Any  intermediate  information  generated  during  execution  of 
PA1.3  and  PA1.4. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Product  must  contain  comprehensive  list  of  Conceptual 
Model  constraints  and  policies  sufficient  to  constrain 
Conceptual  Model  requirements  and  knowledge  needs  in 
keeping  with  direction  and  enterprise  mandates. 

Table  H-5:  Conceptual  Model  Product  1.4  Description. 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

PI .4  -  Conceptual  Model  Meta  Data. 

Product  Description 

•  Product  Definition 

The  conceptual  model  Meta  data  will  address  the  conceptual 
model,  acting  as  its  identifier.  Conceptual  models  are  stored 
together  with  their  Meta  data  specifying  how  they  have  been 
produced,  i.e.,  when,  where,  by  whom,  from  what,  using  what 
tool,  and  so  on. 

•  Product  Purpose 

This  Meta  data  is  necessary  to  ensure  traceability  and 
reusability  of  the  conceptual  model. 

•  Product  Content 

The  Meta  data  template  can  accommodate  a  number  of  meta 
features  of  the  conceptual  model,  for  example:  Name,  Type, 
Version,  Modification  Date,  Security  Classification,  Release 
Restriction,  Purpose,  Application  Domain,  Description,  Use 
Limitation,  Use  History,  V&V  Data  Elements,  Keyword, 
Implementation  Dependencies,  Point  Of  Contact  (POC), 
Reference  and  Glyph. 

•  Product  Structure/Format 

A  table  with  an  entry  for  each  data  element  in  the  Meta  data. 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  Product  development  may  begin  once  PA1.1  begins. 

Product  Development  Guidance 

•  Product  Development 

The  entire  list  of  activities  given  in  text  of  “Product  1 .4 
Guidance”  should  be  completed. 
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Product  Relationships 

•  Product  -  Process  Relationships 

Almost  all  the  Process  Activities  in  all  the  five  Process  Phases 
will  continuously  fill  the  conceptual  model  Meta  data  table  to 
finally  produce  this  product. 

•  Inter-Product  Relationships 

This  product  will  be  developed  concurrently  with  all  other 
products,  and  will  be  updated  and  completed  till  final 
conceptual  model  is  built. 

Associated  Entities 

•  Tools 

No  specific  tools  or  software  to  complete  this  product  has  been 
identified. 

•  Actor- Agents 

No  specific  actor  or  agent  has  been  identified  to  be  alone 
responsible  for  the  development  of  this  product,  however  all 
actors  and  agents  involved  in  the  development  of  the 
conceptual  model  are  responsible  for  filling  the  conceptual 
model  Meta  data  with  the  relevant  data  from  their  activities. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  POC:  Holds  information  about  an  organization  or  a  person 
having  a  particular  role  with  respect  to  the  conceptual 
model. 

•  Model  Identification:  Can  accommodate  information 
related  to  the  identification  of  a  conceptual  model  such  as: 
Name,  Type,  Version,  Modification  Date,  Security 
Classification,  Release  Restriction,  Purpose,  Application 
Domain,  Description,  and  Use  Limitation. 

•  Use  History:  Provides  a  description  of  where  this 
conceptual  model  has  been  used. 

•  Reference:  Specifies  a  pointer  to  additional  sources  of 
information  such  as  locations  in  XML  documents  and 
references  to  ontologies  (both  domain  and  middle  level) 
which  are  used  by  the  conceptual  model. 

•  Implementation  Dependencies:  Maintains  a  log  of  all 
dependencies  determined  during  the  development  of  this 
conceptual  model,  such  as  domain  ontologies  or  any  other 
new  concept  introduced  by  the  process  during  the 
implementation  of  this  conceptual  model. 

•  Key  Word:  Holds  information  about  the  key  words  of  this 
conceptual  model  for  future  use.  It  helps  users  in  searching 
for  this  conceptual  model. 

•  Glyph:  Is  responsible  for  holding  the  image  of  conceptual 
model,  which  can  be  used  to  visually  represent  a 
conceptual  model  in  a  tool  palette  or  a  web  repository. 
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•  Information  Pools  (cont’d) 

•  V&V  Data  Elements:  The  V&V  process  can  produce  an 
enormous  amount  of  data.  These  data  are  collected  under  a 
label  called  V&V  Data  Elements  and  placed  in  the  product 
“conceptual  model  Meta  data”.  In  the  table  below  a  list  of 
data  items  is  presented  together  with  the  Process  Activities 
where  that  data  is  produced. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Product  development  may  end  once  the  Meta  data  table  is 
completed. 

Table  H-6:  Conceptual  Model  Product  2.1  Description 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

P2.1  -  Conceptual  Model  Requirement  Specification. 

Product  Description 

•  Product  Definition 

The  conceptual  model  requirement  specification  documents  a 
collection  of  verifiable  properties,  attributes  and  characteristics 
of  the  Conceptual  Model  necessary  for  it  to  satisfy  its  intended 
purpose. 

•  Product  Purpose 

The  conceptual  model  requirement  specification  shall 
communicate  to  Conceptual  Model  designers  and  builders  all 
intended  uses  of  the  conceptual  model,  the  aspects  of  the 
mission  space  to  be  represented  by  it  and  the  simulator  features 
to  be  supported. 

•  Product  Content 

Requirement  statements  documenting  the  content  of  the 
Conceptual  Model  and  what  criteria  the  Conceptual  Model 
must  satisfy. 

•  Product  Structure/Format 

Each  requirement  must  be  given  a  unique  identifier.  It  may  be 
useful  to  categorizing  the  requirements  as  belonging  to  one  of 
the  three  “spaces”  (Conceptual  Model,  mission,  simulation). 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  At  least  some  of  the  content  or  the  intended  uses  of  the 
simulation  must  have  been  documented. 
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Product  Development  Guidance 

•  Product  Development 

•  Use  the  need  statement  and  constraints  and  policies  inputs  to 
identify  requirements  for  the  Conceptual  Model. 

•  Analyze  the  requirements  with  respect  to  completeness, 
consistency  and  correctness. 

•  Document  the  requirements  in  an  appropriate  format. 

•  Subject  the  requirement  specification  to  review  by  competent 
subject-matter  experts  and  approval  by  the  client. 

Product  Relationships 

•  Product  -  Process  Relationships 

The  conceptual  model  requirement  specification  is  produced 
by  the  process  step  P2.1  Identify,  analyse  and  record  User, 

Mission  and  Simulation  Space  Requirements. 

It  serves  as  an  input  to  the  derivation  of  knowledge  needs  and 
guides  the  development  of  the  Conceptual  Model  design. 

•  Inter-Product  Relationships 

The  conceptual  model  requirement  specification  translates 

PI  .2  -  Need  Statement  and  PI  .3  -  Constraints  and  Policies  into 
verifiable  requirements.  It  spells  out  in  greater  detail  and  more 
precisely  what  is  implied  by  these  inputs.  It  influences  the 

P4.1  -  Conceptual  Model  Design  and  indirectly  the 

P5.1  -  Conceptual  Model  itself. 

Associated  Entities 

•  Tools 

A  requirement  management  tool  may  prove  useful  to  maintain 
traceability  from  needs  to  requirements  and  Conceptual  Model 
content. 

•  Actor- Agents 

The  conceptual  model  requirement  specification  is  produced  in 
collaboration  between  mission  space  and  Modeling  SMEs  and 
subject  to  comment  and  approval  by  the  client. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Scenarios. 

•  Use  cases. 

•  Repository  of  previously  developed  requirement 
specifications. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  The  requirements  for  the  Conceptual  Model  are  sufficiently 
detailed  to  allow  unambiguous  derivation  of  knowledge 
needs  and  Conceptual  Model  design. 
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Table  H-7:  Conceptual  Model  Product  2.2  Description. 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs. 

Product  Description 

•  Product  Definition 

Conceptual  model  knowledge  acquisition  needs  describe  the 
scope  and  level  of  detail  of  knowledge  needed  by  the 

Conceptual  Model  developer  to  produce  a  Conceptual  Model 
satisfying  the  client’s  need  statement. 

•  Product  Purpose 

Conceptual  model  knowledge  acquisition  needs  shall  guide  the 
Conceptual  Model  developer  in  collecting  the  necessary 
knowledge  and  limit  knowledge  acquisition  to  the  minimum 
sufficient  knowledge  set. 

•  Product  Content 

Conceptual  model  knowledge  acquisition  needs  shall  describe: 

•  The  entities  and  activities  in  the  mission  space  the  modeler 
must  understand  in  order  to  represent  them  correctly  and 
with  appropriate  detail. 

•  The  simulation  technique,  tools  and  legacy  assets  the 
modeler  must  understand  in  order  to  represent 
implementation  requirements  and  constraints  correctly. 

•  Product  Structure/Format 

Textual  description. 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  At  least  some  of  the  requirements  for  the  Conceptual 

Model  must  have  been  documented. 

Product  Development  Guidance 

•  Product  Development 

The  developer  must  review  the  Conceptual  Model  requirement 
specification  in  order  to  identify  knowledge  needed  for 
developing  a  Conceptual  Model  with  sufficient  fidelity  to 
satisfy  its  purpose.  Such  knowledge  will  typically  include: 

•  Technologies  applied  in  mission  space  entities  and  their 
capabilities  and  limitations. 

•  Physical  theories  underpinning  these  technologies. 

•  Military  tactics,  techniques  and  procedures. 

•  Candidate  simulation  technologies. 

•  Legacy  simulation  models  and  their  capabilities  and 
limitations. 
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PRODUCT  CHARACTERISTIC 

Product  Relationships 

•  Product  -  Process  Relationships 

Conceptual  model  knowledge  acquisition  needs  are  developed 
in  Process  Activity  PA2.4  -  Derive  Mission  Space  and 

Simulation  Space  Knowledge  Needs.  Knowledge  acquisition 
needs  form  the  input  to  Process  Phase  3  -  Acquire  Conceptual 
Model  Knowledge. 

•  Inter-Product  Relationships 

P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs  are 
developed  based  on  P2.1  -  Conceptual  Model  Requirement 
Specification.  It  is  used  in  order  to  develop  P3.1  -  Validated 
Knowledge. 

Associated  Entities 

•  Tools 

Not  applicable. 

•  Actor- Agents 

The  main  agents  participating  in  the  development  of 

Conceptual  Model  knowledge  needs  are  subject-matter  experts 
from  the  military  mission  domain,  the  military  technology 
domain  and  modeling  and  simulation  domain. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  Previously  developed  knowledge  needs  descriptions. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  A  description  of  the  knowledge  needed  for  Conceptual 

Model  development  has  been  developed  that  is  sufficiently 
comprehensive  and  specific  to  serve  as  guidance  for  the 
knowledge  acquisition  phase. 

Table  H-8:  Conceptual  Model  Product  3.1  Description. 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

P3.1  -  Validated  Knowledge. 

Product  Description 

•  Product  Definition 

The  product  Validated  Knowledge  is  produced  in  the  NATO 
conceptual  modeling  Process  Phase  3,  called  Acquire 

Conceptual  Model  Knowledge.  It  is  a  validated  piece  of 
knowledge,  developed  in  response  to  an  identified  need  and/or 
requirement  in  the  previous  phase  (2).  It  will  be  acquired  from 
authoritative  knowledge  sources,  and  then  will  be  structured, 
documented,  and  validated  with  respect  to  that  authoritative 
knowledge  source. 
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PRODUCT  CHARACTERISTIC 

•  Product  Purpose 

This  will  be  the  sole  and  very  important  product  produced 
during  Phase  3.  The  next  phase  Design  the  Conceptual  Model 
will  use  this  product  to  design  a  conceptual  model.  It  is  to  say 
that  this  product  will  serve  as  the  foundation  for  designing  and 
building  the  final  conceptual  model. 

•  Product  Content 

A  structured  and  documented  piece  of  knowledge  which  has 
been  validated  with  respect  to  the  authoritative  knowledge 
sources. 

•  Product  Structure/Format 

No  mandated  format. 

Product  Initiation 

•  Entrance  Criteria 

Entrance  criteria  consists  of  the  following  activities, 
availability  of  information  and  establishment  of  operational 
capability: 

•  The  knowledge  needs  and  the  requirements  list  from  the 
previous  phase  (2)  are  required. 

•  Access  to  an  existing  conceptual  model  repository  with 
reusable  knowledge  is  beneficial  and  preferred. 

•  A  list  of  the  authoritative  knowledge  sources  for  the 
required  knowledge  is  also  advantageous. 

Product  Development  Guidance 

•  Product  Development 

After  identifying  the  needs  and  the  requirements  for  the 
knowledge  which  were  done  in  the  previous  phase  (2),  the 
authoritative  knowledge  sources  for  the  particular  knowledge 
which  is  requested  are  identified.  Next  activity  in  the  process 
will  start  looking  for  the  corresponding  reusable  knowledge 
which  may  already  exist  in  an  existing  conceptual  model 
repository,  knowledge  that  can  totally  or  partly  be  usable  for 
this  new  need.  If  not,  the  lack  of  knowledge  and  the  gaps  which 
must  be  filled  is  identified.  After  that  the  knowledge  will  be 
gathered,  structured  and  documented.  Next,  there  should  be 
enough  information  to  either  generate  domain  ontology  for  this 
particular  mission  space  or  extend  existing  domain  ontology. 
Finally  the  validity  of  the  acquired  knowledge,  with  respect  to 
the  authoritative  knowledge  sources,  will  be  reviewed  and  this 
product  will  be  produced. 

Product  Relationships 

•  Product  -  Process  Relationships 

This  is  the  final  product  of  Phase  3  in  the  NATO  conceptual 
model  Process,  and  to  produce  it  one  should  go  through  the 
Process  Activities  PA3.1  to  PA3.6. 

•  Inter-Product  Relationships 

Products  P2.1  -  Conceptual  Model  Requirement  Specification 
and  P2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs 
are  the  predecessors  and  P4.1  -  Conceptual  Model  Design  is 
the  successor  to  this  product. 
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PRODUCT  CHARACTERISTIC 

Associated  Entities 

•  Tools 

This  product  is  a  result  of  a  knowledge  development  process 
and  thus  support  of  appropriate  tools,  methods,  and  techniques 
from  the  knowledge  development  area  is  very  much 
appreciated,  such  as: 

•  Methodologies  for  acquisition  of  data,  information,  and 
knowledge. 

•  Methodologies  for  documentation,  representation,  and 
formatting  the  acquired  knowledge. 

•  Tools  for  knowledge  acquisition,  representation, 
formalization,  etc. 

•  Tools  for  managing  and  maintaining  ontologies. 

•  Actor- Agents 

•  Knowledge  engineer;  to  provide  experience  in  acquiring, 
gathering  and  compiling  information. 

•  SME;  to  provide  the  domain  and  task  knowledge. 

•  Analysis  and  formatting  expert;  experienced  in  the 
appropriate  formatting  analysis  method  and  technique. 

•  Ontology  expert;  experienced  in  mapping  and  interpreting 
information  held  in  the  ontology,  as  well  as  being  skilled 
in  how  to  further  develop  and  extend  ontologies. 

•  VV&A-agent;  for  validating  the  result. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  An  existing  conceptual  model  repository  with  reusable 
knowledge. 

•  Domain  ontologies  in  a  knowledge  base  are  very  much 
appreciated  but  not  mandatory. 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  The  Process  Activity  3.6  -  Review  Validity  of  Acquired 
Knowledge  with  Respect  to  the  Authoritative  Knowledge 
Sources  will  guarantee  that  the  product  lives  up  to  the 
expectations. 

Table  H-9:  Conceptual  Model  Product  4.1  Description 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

P4. 1  -  Conceptual  Model  Design. 
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PRODUCT  CHARACTERISTIC 

Product  Description 

•  Product  Definition 

Document  recording  the  conceptual  model  design  decisions 
with  a  justification  of  the  elective  choice. 

•  Product  Purpose 

This  product  serves  as  a  blue  print  to  build  the  conceptual 
model. 

•  Product  Content 

Conceptual  model  design  shall  describe: 

•  A  record  of  conceptual  model  composites:  conceptual 
primitives,  model  kinds,  views,  formalisms  and  notations. 

•  A  justification  of  each  design  decision  with  traceability  to 
the  driving  requirement. 

•  Product  Structure/Format 

No  mandated  format. 

Product  Initiation 

•  Entrance  Criteria 

Product  development  may  begin  as  soon  as  PP4  begins. 

Product  Development  Guidance 

•  Product  Development 

Iteratively: 

•  Make  elective  choices  of  conceptual  model  composites. 

•  Reconcile  choices  into  a  coherent  conceptual  model 
composite  combination. 

•  Evaluate  the  conceptual  model  design  for  adequacy/ 
relevance  with  the  conceptual  model  requirements. 

Product  Relationships 

•  Product  -  Process  Relationships 

The  product  exists  in  a  preliminary  form  over  PA4.1  to  PA4.5 
iterations.  PA4.6  produces  the  final  P4.1  product,  which  is  used 
by  PA5.1.  P4.6  also  uses  this  product  to  evaluate  the  design 
and  update  PI  .4  -  Conceptual  Model  Meta  Data  accordingly. 

•  Inter-Product  Relationships 

This  product  completely  relies  on  P2.1  -  Conceptual  Model 
Requirement  Specification  and  may  be  used  to  produce 

P5.1  -  Conceptual  Model  as  soon  as  it  has  valuable  input. 

It  may  evolve  iteratively  with  P5. 1 . 

Associated  Entities 

•  Tools 

No  specific  tool  is  required  to  document  the  selection  of 
conceptual  model  composites.  A  requirement  management  tool 
could  be  useful  to  document  traceability. 

•  Actor- Agents 

Producers. 

•  Information  Pools 

Information  pools  relevant  to  this  activity  include: 

•  P2.1  -  Conceptual  Model  Requirement  Specification, 
preliminary  conceptual  model  design  and  literature  surveys. 
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PRODUCT  CHARACTERISTIC 

Product  Completion 

•  Exit  Criteria 

Criteria-types  for  demonstration  of  satisfactory  completion  of 
the  subject  activity,  include  the  following: 

•  Product  must  pass  PA4.6  evaluation  against 

P2.1  -  Conceptual  Model  Requirement  Specification. 

Table  H-10:  Conceptual  Model  Product  5.1  Description 


PRODUCT  CHARACTERISTIC 

Product  Identity 

•  Product  Name  and  Aliases 

P5.1  -  Conceptual  Model. 

Product  Description 

•  Product  Definition 

The  authorized  conceptual  model  work-product  resulting  from 
the  conceptual  modeling  activity  and  including  collateral 
materiel  generated  during  the  conceptual  modeling  effort  as  are 
necessary  and  sufficient  to  qualify  the  conceptual  model  product 
artefact  per  se  and  to  support  its  evolution  an  use  in  context  of 
the  simulation  enterprise  environment  for  which  it  was  produced. 

•  Product  Purpose 

The  purpose  of  this  work-product  is  to  document  in  systematic, 
persistent,  authoritative  and  detailed  form  information 
constituting  the  subject  conceptual  model  in  order  to  support 
simulation  development  operations  and  maintenance  as  well  as 
model  and  simulation  re-use  throughout  the  duration  of  the 

M&S  enterprise. 

•  Product  Content 

Product  contains  full  and  detailed  articulation  of  the  mission 
space  and  simulation  space  ontology  (entities,  attributes, 
behaviours,  and  relationships)  that  is  necessary  and  sufficient 
to  support  simulation  development  and  life-cycle  evolution. 

•  Product  Structure/Format 

Product  structure  is  elective  in  accordance  with  decisions  made 
during  the  conceptual  modeling  process;  including  particularly 
election  of  conceptual  model  primitives,  model  kinds, 
formalism,  views,  design  features,  mission-  and  simulation- 
space  information  to  be  made  manifest  in  the  preliminary  (and 
final)  conceptual  model.  Documentary  conventions  and  media 
are  likewise  left  to  the  developer  insofar  as  they  are  decided 
explicitly,  consistently,  and  in  conformance  with  protocols  and 
strategic  guidance  associated  with  the  M&S  enterprise. 

Product  Initiation 

•  Entrance  Criteria 

Product  development  proper  (i.e.,  in  addition  to  the 
compilation  of  ancillary  information  products  generated  during 
the  conceptual  modeling  process),  begins  at  completion  of 

Activity  PP4. 
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Product  Development  Guidance 

•  Product  Development 

Activity  PP5  and  its  sub-sections  PA5.1  through  PA5.5  specify 
in  detail  product  development  activity. 

Product  Relationships 

•  Product  -  Process  Relationships 

See  PA5.1  -  PA5.5. 

•  Inter-Product  Relationships 

Products  directly  input  to  the  generation  of  Product  P5.1  are 

P3.1  -  Validated  Knowledge  and  P4.1  -  Conceptual  Model 
Design. 

Associated  Entities 

•  Tools 

CASE  tools  implied  by  the  conceptual  model  design  and 
implementation  process  elements  are  relevant  to  the  generation 
of  the  subject  product. 

•  Actor- Agents 

Conceptual  product  development  team. 

•  Information  Pools 

Information  contained  in  P3.1  and  P4.1  are  required  as  input  to 
the  subject  work-product. 

Product  Completion 

•  Exit  Criteria 

Approval  of  FINAL  DRAFT  conceptual  model  by  authoritative 
stakeholder(s). 
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Annex  I  -  CONCEPTUAL  MODEL  EXAMPLES 


This  document  deliberately  presented  guidance,  as  opposed  to  specification,  to  conceptual  modeling  to  capture 
the  essential  best-practices  while  remaining  tailorable  to  a  broad  range  of  enterprise  contexts.  In  this  line, 
this  annex  presents  examples  to  illustrate  the  various  Process  Activities  and  Products. 

The  objective  of  this  annex  is  to  guide  the  reader  in  the  implementation  of  a  conceptual  modeling  process  and 
conceptual  model  products  in  its  own  enterprise  context  while  avoiding  restricting  it  to  standard  templates. 
The  examples  are  intended  to  clarify  the  most  abstract  parts  of  the  guidance,  to  bring  out  the  range  of  applicability 
and  to  expose  important  issues. 

For  conciseness  and  time  constraints,  no  thorough  end-to-end  example  is  included  and  trivial  parts  have  been 
omitted.  The  examples  have  been  selected  amongst  a  number  of  current  enterprise  practices.  The  domain 
covered  by  the  examples  must  not  be  taken  as  a  limitation  to  the  scope  of  applicability  of  the  guidance. 

Example  1-1  differentiates  between  conceptual  model  space,  mission  space  and  simulation  space  requirements 
and  demonstrates  how  to  derive  knowledge  needs  from  requirements.  Example  1-2  presents  a  method  to: 
gather,  structure  and  document  knowledge;  generate  domain  ontology;  and,  use  this  knowledge  to  design  and 
build  conceptual  model  artefacts.  Example  1-3  differentiates  the  representation  of  mission-space  knowledge, 
simulation-space  knowledge  and  the  conceptual  model  of  a  simulation.  Example  1-4  presents  sample 
conceptual  model  artefacts  based  on  a  community-specific  conceptual  model  design.  Finally,  Example  1-5 
illustrates  the  iterative  evolution  of  a  conceptual  model  requirements,  design  and  artefacts. 


LI  DEFINING  CONCEPTUAL  MODEL  REQUIREMENTS  AND  DERIVING 
KNOWLEDGE  NEEDS 

1.1.1  Process  Activity  2.1  -  Identify,  Analyze  and  Record  Conceptual  Model,  Mission  and 
Simulation  Space  Requirements 

In  Process  Activity  2.1,  the  conceptual  model  requirements  are  identified,  analyzed  and  recorded.  It  is  suggested 
to  address  the  conceptual  model  requirement  definition  in  terms  of  conceptual  model  space,  mission  space  and 
simulation  space  requirements.  The  objective  of  this  example  is  to  differentiate  between  conceptual  model  space, 
mission  space  and  simulation  space  requirements  and  to  demonstrate  what  is  inclusive  in  the  conceptual 
modeling  process.  This  example  was  developed  by  the  MSG-058  Task  Group  in  testing  several  requirements 
against  the  three-space  classification.  Although  very  partial,  the  artefact  in  Table  1-1  is  an  example  of 
Product  2.1  -  Conceptual  Model  Requirement  Specification.  The  conceptual  model  requirement  classification 
may  be  arbitrary  and  is  not  error  proof.  The  key  point  is  to  be  all  inclusive  when  capturing  conceptual  model 
requirements. 
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Table  1-1:  Examples  of  Conceptual  Model  Requirements  Categorized  in  Terms 
of  Conceptual  Model  Space,  Mission  Space  and  Simulation  Space. 


Conceptual  Model  Space 
Conceptual  Model  requires. . . 

Mission  Space 

Conceptual  Model  requires. . . 

Simulation  Space 
Conceptual  Model  requires. . . 

To  have  views  adapted  to  each 
stakeholder 

To  represent  a  battalion 

To  represent  a  decision-maker 
training  simulation 

To  be  useful  for  interoperability 
within  NATO 

To  represent  the  command  and 
control  system 

To  represent  the  live  usage  of  a 
decision  support  tool 

To  be  readable  by  a  computer 

To  represent  a  peace  keeping 
mission 

To  represent  fair  fight 

To  be  readable  in  French 

To  represent  insurgents 

To  represent  an  HLA  simulation 

1.1.2  Process  Activity  2.4  -  Derive  Mission  Space  and  Simulation  Space  Knowledge  Needs 

In  Process  Activity  2.4,  the  mission  space  and  simulation  space  knowledge  needs  are  derived.  The  objective  of 
this  example  is  to  demonstrate  how  to  derive  knowledge  needs  from  requirements.  Table  1-2  presents  knowledge 
needs  derived  from  a  few  requirements  of  Table  1-1.  Although  very  partial,  the  artefact  in  Table  1-2  is  an 
example  of  Product  2.2  -  Conceptual  Model  Knowledge  Acquisition  Needs.  Deriving  knowledge  needs  requires 
experience  and  it  is  more  easily  done  iteratively.  The  outcome  can  turn  out  to  be  arbitrary,  thus  a  special  effort 
must  be  made  to  avoid  preconceived  ideas  to  produce  an  objective  knowledge  need  statement. 


Table  1-2:  Examples  of  Conceptual  Model  Knowledge  Needs  Derived  from 
Some  of  the  Sample  Conceptual  Model  Requirements  of  Table  1-1. 


Space 

Conceptual  Model  Requirements 

Conceptual  Model  Knowledge  Needs 

Simulation 

Space 

+ 

Mission  Space 

•  To  represent  a  battalion 

•  To  represent  the  live  usage  of  a 
decision  support  tool 

•  Need  knowledge  on  battalion 
composition,  humans,  equipments,  etc., 
at  the  level  of  detail  supported  by  the 
decision  tool  and  at  the  level  of  fidelity 
detectable  by  the  tool 

•  Need  knowledge  from  a  tank  driver, 
from  a  physicist,  etc. 

Simulation 

•  To  represent  the  live  usage  of  a 
decision  support  tool 

•  Need  knowledge  in  the  decision  support 
tool  inputs 

•  Need  the  minimum  detectable 
thresholds  for  each  input 

Simulation 

•  To  represent  an  HLA  simulation 

•  Need  knowledge  on  the  HLA  concepts: 
classes,  interactions,  time  management, 
data  management,  etc. 

Simulation 

•  To  represent  a  decision-maker  training 
simulation 

•  Need  knowledge  on  the  human  interface 

•  Need  knowledge  on  the  evaluation 
metrics 
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1.2  FROM  KNOWLEDGE  ACQUISITION  TO  KNOWLEDGE  USE  IN  A 
CONCEPTUAL  MODEL 

This  example  is  taken  from  the  Swedish  Defence  Conceptual  Modeling  Framework  (DCMF)  Project  [1]. 
The  DCMF  process  could  be  an  implementation  of  the  proposed  conceptual  modeling  guidance.  It  is  divided 
in  four  main  phases:  knowledge  acquisition,  knowledge  representation,  knowledge  modeling  and  knowledge 
use. 

The  example  is  written  as  straight  forward  steps  to  introduce  sample  product  artefacts  although,  in  reality, 
the  knowledge  acquisition  and  the  conceptual  model  construction  have  been  done  iteratively.  The  proposed 
conceptual  modelling  guidance  does  not  prevent  to  produce  conceptual  model  artefacts  to  represent  the 
knowledge  as  it  is  acquired  to  help  acquiring  more  knowledge.  In  fact,  it  is  rather  advised  to  do  so.  This  is  part 
of  the  modeling  art. 

This  example  presents  the  conceptual  model  of  a  scenario,  as  opposed  to  the  conceptual  model  of  a  system. 
The  sample  scenario  is  taking  place  in  Kosovo  and  its  surroundings,  in  May  2002.  NATO  forces  are  conducting 
a  Peace  Support  Operation  in  order  to  regain  stability  and  security  in  Kosovo.  A  Swedish  patrol  (KS05)  from  the 
Swedish  peace  keeping  force  discovers  a  looted  weapons  depot  and  report  this  into  the  information  system  of  the 
Swedish  Intelligence.  An  intelligence  officer  in  Sweden  receives  the  report  and  starts  a  further  investigation. 
Information  from  different  sources  leads  to  the  estimate  that  the  missing  weapons  might  be  smuggled  to  Sweden 
by  organized  criminals.  Cooperation  between  different  military  and  civil  organizations  to  acquire  information 
leads  to  the  confiscation  of  the  weapons  in  the  harbor  of  Gothenburg  in  Sweden. 

1.2.1  Process  Activity  3.4  -  Gather,  Structure  and  Document  Knowledge 

Process  Activity  3.4  consists  in  gathering,  structuring  and  documenting  knowledge  to  ultimately  produce  a 
conceptual  model.  The  objective  of  this  example  is  to  illustrate  a  method  for  performing  Process  Activity  3.4. 

In  this  example,  knowledge  acquisition  was  performed  using  video  clippings  and  in-depth  interviews  carried 
out  with  subject-matter  experts  for  further  clarification  and  enrichment  of  the  scenario  description.  It  resulted 
in  a  description  of  the  scenario  in  natural  language,  for  which  an  excerpt  corresponding  to  paragraph  1  is 
presented  in  Table  1-3. 

Table  1-3:  Sample  Scenario  Description  in  Natural  Language  (Paragraph  1). 


A  Swedish  patrol  from  a  battalion  in  Kosovo  finds  weapons  in  the  forest  near  a  village  called  Janjevo. 
The  finding  is  reported  in  the  battalion's  intelligence  report  and  this  is  transferred  in  code  to 
Stockholm.  The  information  about  the  finding  is  received  by  the  Intelligence  Division  at  MUST  and  the 
report  is  registered  in  the  System.  The  information  about  the  found  weapons  is  made  available  for  the 
department  of  international  intelligence  (MUST  IntUnd). 


Then,  implicit  and  explicit  knowledge  was  represented  from  the  natural  language  description.  Table  1-4 
presents  some  implicit  knowledge  inferred  from  paragraph  1  of  the  scenario  description  in  natural  language. 
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Table  1-4:  Sample  Implicit  Knowledge  Inferred  from  the  Scenario  Description. 


•  There  is  a  Peace  Support  Operation  in  Kosovo  sometime  in  MAY  2002,  of  which  the  Swedish 
contingent  is  a  part  of  (Inferred  from  background  context  material). 

•  Janjevo  is  a  geographical  location  in  Kosovo. 

•  There  is  a  forest  near  Janjevo. 

•  Swedish  troops  go  on  regular  patrol  missions. 

•  There  is  a  procedure  (military)  to  be  followed  by  any  military  PATROL  if  they  are  on  a  patrolling 
mission.  It  also  implies  that  there  would  be  standard  operating  procedures  and  regulations 
governing  this  process  of  patrolling. 

•  ' Swedish  ’  implies  that  Sweden  is  a  sovereign  nation,  and  that  it  has  military  capability,  and  is  part 
of  the  UN  Peace  Support  Operations. 

•  Weapons  are  hidden,  that  is,  they  are  obscured  from  normal  sight  and  they  are  not  left  for  public 
viewing. 


Explicit  knowledge  can  be  extracted  using  different  methods.  Table  1-5  presents  the  results  of  the  Five  Ws 
method  applied  on  paragraph  1  of  the  scenario  description  in  natural  language. 


Table  1-5:  Sample  Explicit  Knowledge  Extracted  from  the 
Scenario  Description  Using  the  Five  Ws  Method. 


Who 

Patrol  from  Swedish  contingent 
KS05 

Patrol:  Military  type  Organization  (under  govt, 
type  object-type:  Unit-Type:  has  Affiliation 
object  type  relation  to 

Swedish  Contingent:  Object-Item-Group 

Swedish:  Affiliation 

What 

Patrolling 

Patrolling:  Action-task  purpose:  WHY  AOI: 
Location 

When 

From  1st  May  to  3 1st  May  2002 

Why 

To  secure  AOI 

Where 

AOI  somewhere  in  Kosovo 

AOI:  Specification  detail  AOI  is  both  a 

Location  as  well  as  a  CONTROL  FEATURE: 
may  even  be  a  sub-type  of  control  -  feature 
like  ROUTE,  etc. 

Table  1-6  presents  the  results  of  the  Knowledge  Meta  Meta  Model  (KM3)  methodology  [1]  applied  on  paragraph 
1  of  the  scenario  description  in  natural  language. 
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Table  1-6:  Sample  Explicit  Knowledge  Extracted  from  the 
Scenario  Description  Using  the  KM3  Method. 


Entity  Type  ::  Swedish  patrol 
Entity  Type  ::  Contingent  in  Kosovo 

ElementComposition  :  <Swedish  patrol ,  Contingent  in  Kosovo> 

Entity  Type  ::  Weapons 
Entity  Type  ::  Forest 

Attribute  :  Close  to  ET:Janjevo,  in  kilometers 
CompositionType  :  RangedAttribute 
Domain  :  Distance 
Start  Value  :  0 
Stop  Value  :  10 
Entity  Type  ::  Janjevo 
Attribute  :  Village  in  Kosovo 

CompositionType  :  RangedAttribute 
Domain  :  Inhabitants 
Start  Value  :  100 
Stop  Value  :  1000 
Action  Type  ::  Finds 
Time  :  May  2002 
RolelnAction  :  <finder,  patrol> 

RolelnOrganisationType  :  <patrol,  ET:  Swedish  patrol> 

Criterion  ::  SF:  (prob  1,  is  St  art  Criterion  t, 

[Swedish  patrol :  onPatrol  AND  Forest  AND  Weapons]) 

State:  found  weapons 

ActivityState  :  Finding  weapons  (has  occurred)  /*  activity  Finds  has  occurred  */ 

Entity  Type  :  Swedish  patrol 

State:  alerted  AND  onPatrol 
Entity  Type  ::  Weapons 
State:  found 


1.2.2  Process  Activity  3.5  -  Generate/Extend  a  Domain  Ontology 

In  Process  Activity  3.5,  the  knowledge  captured  in  previous  activities  is  formalized  semantically  as  domain 
ontology.  The  objective  of  this  example  is  to  illustrate  how  to  generate  domain  ontology.  This  example  uses 
the  knowledge  of  example  1-2.1  to  translate  it  in  domain  ontology. 

The  knowledge  was  modeled  through  a  semantic  mapping  of  the  semi-structured  information.  The  implicit 
knowledge  was  merged  with  the  explicit  knowledge  in  a  machine  readable  format,  namely  in  the  DCMF 
ontology  developed  using  the  Web  Ontology  Language  (OWL)  [2].  Table  1-7  lists  some  of  the  concept  (class) 
types  that  were  instantiated  to  model  the  sample  scenario  paragraph. 
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Table  1-7:  Sample  Ontology  Classes  Instantiated  to  Document  the  Scenario. 

•  Action-Task 

•  Action-Task-Status 

•  Action-Objective-Type  (securing  area  of  interest) 

•  Action-Required-Capability  (for  patrol  mission)  related  to 

•  Action-Event-Status:  (through  this  it  is  associated  to  action-event.  Finding  weapons  in  a  particular 
action-task:  patrolling.) 

•  Reporting-data 

•  Action-Event 

•  Object-Item-Group-Account:  (the  composition  or  relation  of  object  types  involved  in  the  patrolling 
action.) 

•  Capability:  sub  type:  Mission-Capability:  (specifies  required  parameters  for  carrying  out  a  patrol.) 

•  Affiliation 

•  Context 

•  Location 

•  Control  Feature 

•  Action-Temporal-Association:  time  events,  sequences  and  info  for  placing  the  action  tasks  and  events 
in  temporal  sequence 

•  Object-Type:Equipment-Type:Non-Consummable-Equipment-Type:  Weapons 


Table  1-8  presents  an  excerpt  of  the  OWL  code  format  for  the  Patrol  Mission  instance  of  the  Action-Required- 
Capability  concept  from  the  sample  scenario  paragraph.  The  artefact  in  Table  1-8  is  an  example  of  Product  3.1 
-  Validated  Knowledge. 
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Table  1-8:  Sample  OWL  Code  for  the  Patrol  Mission  Instance  of  the 
Action-Required-Capability  Class  Capturing  the  Scenario  Knowledge. 


<Action-Required-Capability  rdf : ID=Mpatrolreqdqty"> 

<quantif ies> 

<Mission-capability  rdf : ID="patrolmissionM> 

<capability-id  rdf : datatype=Mhttp : / / www . w3 . org/ 2 001/XMLSchema#string" 
>CMmscapability2</capability-id> 

<capability-unit -of -measure -code  rdf : datatype=  "http : //www . w3 . org/2001/XMLSchema#string" 
>square-metres-per-hour</ capability- unit -of -measure -code> 

<is-quantif ied-in  rdf : resource=" #patrolreqdqty" /> 

<capability- subcategory- code  rdf : datatype="http : //www . w3 . org/2001/XMLSchema#string" 
>maximum-Range</capability-subcategory-code> 

<capability-category-code  rdf : datatype="http : / /www. w3 . org/2001/XMLSchema#string" 
>military-load-capability</ capability- cat egory-code> 

<capability-day-night-code  rdf : datatype="http : //www. w3 . org/2001/XMLSchema#string" 
>day-and-night</capability-day-night-code> 

</Mission-capability> 

</quantif ies> 

<capability-id  rdf : datatype="http : //www . w3 . org/2001/XMLSchema#string" 
>CMmscapabilityidl</capability-id> 

<is-minimum-required-f or  rdf : resource="#actioneventstatusl"/> 
<action-required-capability-quantity  rdf : datatype= 

"http : //www . w3 . org/2001/XMLSchema#int ">15</ act ion- required- capability-quant ity> 
<action-id  rdf : datatype="http : //www . w3 . org/2001/XMLSchema#string" 
>patrol_reqd_qty</action-id> 

</Action-Required-Capability> 


Figure  1-1  illustrates  how  the  Patrol  Mission  instance  is  represented  in  the  Protege  ontology  editor  [3].  In  this 
example,  the  capability  categories  have  been  imported  from  the  Joint  C3  Information  Exchange  Data  Model 
(JC3IEDM)  [4],  which  is  an  illustration  of  knowledge  reused  following  Process  Activity  3.2. 
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Figure  1-1:  Sample  Scenario  Knowledge  (Patrol  Mission  Object)  in  the  Protege  Ontology  Editor. 


1.2.3  Process  Phase  4  -  Design  Conceptual  Model 

A  conceptual  model  is  used  to  contain  and  represent  the  knowledge  in  a  construct  that  will  fit  the  type  of 
knowledge  acquired  during  Process  Phase  3  and  that  will  allow  to  make  use  of  that  knowledge.  In  Process 
Phase  4,  the  conceptual  model  design  is  driven  by  the  intended  purpose  captured  in  Product  2.1  -  Conceptual 
Model  Requirement  Specification.  The  objective  of  this  example  is  to  illustrate  a  few  design  options  to  fit 
different  usages  of  the  conceptual  model.  The  artefact  in  Table  1-9  is  an  example  of  Product  4.1  -  Conceptual 
Model  Design. 
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Table  1-9:  Conceptual  Model  Design  for  the  Scenario  Description  Example. 


Component 

Design 

Build 

Conceptual 

Primitives 

Pool 

Swedish  Contingent,  MUST 

Activity 

Patrol  Mission,  File  Area  Clear  Report,  etc. 

Event 

Send  Search,  Interrogate  Order/Request 

Gateway 

Area  Secure,  Analyze  Results 

Actor 

Intel  Officer,  Depot  Personnel 

Use  Case 

Report  File  to  MUST,  Check  Information 
System 

Model  Kinds 

Collaboration  process  diagram, 
composed  of  2  Abstract  process 
diagrams 

Use  Case 

Views 

Simplest  human  understandable  high- 
level  description  of  the  scenario 

See  Figure  1-1 

Collaboration  between  organizations 

See  Figure  1-3 

Comparison  of  a  scenario  procedure  to 
a  recommended  procedure 

See  Figure  1-4 

Formalisms 

BPMN 

Use  Case 

Notations 

BPMN 

Custom  Pictogram 

Process  Activity  4.1  suggests  that  the  conceptual  model  design  may  be  influenced  by  the  design  of  another 
conceptual  model  being  reused.  In  this  example,  no  existing  conceptual  model  was  reused  and  no  constraint  of 
that  sort  was  imposed  on  the  design. 

In  Process  Activity  4.2,  conceptual  primitives  fit  for  the  type  of  knowledge  are  selected.  The  current  example 
involves  the  conceptual  model  of  a  military  scenario.  Therefore,  appropriate  conceptual  primitives  are  actors, 
activities,  events,  etc.  Eligible  model  kinds  that  represent  interactions  between  scenario  elements  include 
collaboration,  activity,  sequence,  and  use  case  diagrams. 

Different  formalisms  allow  representing  these  combinations  of  conceptual  primitives  and  model  kinds:  Petri 
Nets,  ontology,  use  case,  BPMN,  etc.  In  Process  Activity  4.3,  the  formalism  choice  is  influenced  by  the 
conceptual  model  requirement  specification.  In  this  example,  the  conceptual  model  was  intended  for  visualisation 
purpose  for  communication  with  the  subject-matter  experts  and  for  process  optimization  or  conformance 
checking  by  analysts.  Graphical  expressiveness  was  a  key  driver  to  present  information  to  participants  while 
robust  inference  for  system  interoperability  was  not  an  intended  use  of  the  conceptual  model.  The  use  case 
formalism  was  selected  for  its  simplicity  (only  actors  and  use  cases).  BPMN  [5]  was  privileged  over  Petri  Nets 
and  ontology. 
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The  targeted  stakeholders  and  intended  purpose  drive  the  selection  of  views  during  Process  Activity  4.4. 
Custom  views  can  be  created  from  the  generic  conceptual  model  content.  For  example,  a  simple  high-level 
description  of  the  scenario  is  created  for  communication  with  the  subject-matter  experts.  An  organisational 
collaboration  view  and  a  procedure  comparison  view  are  appropriate  to  the  work  of  the  process  analysts. 
In  addition  to  these  process  views,  others  views  could  have  useful  to  other  usages,  for  example  component  or 
deployment  views  to  model  the  communications  between  information  systems. 

In  Process  Activity  4.5,  a  notation  is  selected  to  implement  the  chosen  formalism.  BPMN  is  a  formalism  that 
comes  with  its  own  notation,  a  frequent  practice  in  the  modeling  domain.  The  BPMN  notation  was  chosen 
over  the  UML  notation  because  of  its  graphical  expressiveness,  a  driving  requirement  in  this  example.  BPMN 
supports  a  few  model  kinds  and  their  conceptual  primitives  (Pool,  Activity,  Event,  Gateway).  The  same 
Collaboration  Process  Diagram  model  kind  is  used  to  produce  two  different  views.  For  the  same  reason, 
a  custom  pictogram  notation  was  selected  over  the  UML  notation  to  express  the  use  case  formalism. 

Finally,  as  advised  in  Process  Activity  4.6,  the  conceptual  model  conformance  to  the  requirements  should  be 
verified.  Formal  metrics  could  be  derived  to  measure  how  fit  is  the  conceptual  model  for  the  specific  purposes. 
In  this  example  illustrated  in  Table  1-9,  only  the  overall  stakeholders’  work  efficiency  proved  the  conceptual 
model  usefulness. 

1.2.4  Process  Phase  5  -  Build  Conceptual  Model 

In  Process  Phase  5,  the  validated  knowledge  produced  (Product  3.1)  is  used  to  populate  the  content  (conceptual 
primitives)  of  the  conceptual  model.  The  objective  of  this  example  is  to  illustrate  the  different  views  generated 
from  the  conceptual  model  based  on  the  knowledge  of  example  1-2.2  and  the  design  choices  (formalism, 
notation,  model  kinds)  summarized  in  Table  1-9. 

Figure  1-2  presents  the  simplest  human  understandable  high-level  description  of  the  scenario  using  a  custom 
pictogram  notation  to  express  the  use  case  formalism.  Figure  1-3  shows  the  collaboration  between  organizations 
and  Figure  1-4  compares  the  organizational  procedures,  both  using  collaboration  process  diagrams  from 
BPMN. 
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eiOfficer  aligned  to  Investigate 


Find  ;  List  of  Weapons 
Depot  in  the  same  vicinity 


Send  missing  weapons  | — sen(js  intelligence  Requests 

and  person  status  report 


Inventory  checked  at  each  depot 


Officer  reports  beliefs  that 
missing  weapons  are  smuggled  to  Sweden 


Dept.  Of  Security 


'n  1  Case  handler  assigned  investigates 

reports  and  concurs 
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Figure  1-2:  Sample  View  of  the  Conceptual  Model  of  the  Scenario  Allowing  to  Visualize 
the  Simplest  Human  Understandable  High-Level  Description  of  the  Scenario. 
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Figure  1-3:  Sample  View  of  the  Conceptual  Model  of  the  Scenario 
Allowing  Visualizing  the  Collaboration  Between  Organizations. 
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the  Scenario  Allowing  to  Compare  Procedures. 


The  artefacts  in  Figure  1-2  to  Figure  1-4,  all  together,  are  an  example  of  Product  5.1  -  Conceptual  Model. 


1.3  RELATION  BETWEEN  KNOWLEDGE  REPRESENTATION  AND  A 
CONCEPTUAL  MODEL 

The  proposed  conceptual  modeling  guidance  does  separate  the  knowledge  documentation  in  Process  Phase  3 
from  the  conceptual  model  of  a  simulation  in  Process  Phases  4  and  5.  In  reality,  similar  documentation 
techniques  may  be  used  for  both.  The  objective  of  this  example  is  to  differentiate  the  representation  of  mission- 
space  knowledge,  simulation-space  knowledge  and  the  conceptual  model  of  a  simulation. 

This  example  is  taken  from  the  Canadian  IMAGE  Project  [6].  It  presents  the  conceptual  model  of  a  military 
mission  to  be  simulated.  The  mission  is  a  humanitarian  operation  to  reconstruct  a  school  in  a  rugged  region 
akin  to  Afghanistan.  It  involves  convoys  subjected  to  IEDs  and  evolving  within  a  dynamical  social  terrain. 
Blue  friendly  forces  and  red  insurgents  compete  for  recruiting  the  allegiance  of  the  general  population. 
The  convoys  utilize  different  roads  or  tracks  over  time,  some  with  limiting  conditions  related  to  the  3D 
ruggedness  of  the  terrain.  Mine  attacks  occur  with  a  probability  that  depends  of  the  type  of  physical  and  social 
grounds  being  travelled  and  type  of  carriers  used. 
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1.3.1  Process  Activity  3.4  -  Gather,  Structure  and  Document  Knowledge 

In  Figure  1-5,  the  mission-space  knowledge  is  structured  and  document  using  conceptual  graphs  [7]  in  the 
CoGUI  tool  [8].  In  Figure  1-6,  the  simulation-space  knowledge  is  represented  using  a  hierarchy  of  the  simulation 
framework  concepts,  in  this  case,  a  custom  Canadian  simulation  framework. 


Figure  1-5:  Sample  Mission-Space  Knowledge  Documentation. 
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'Sfr  CoGUI-IMAGE  -  ImageScenarioV2-.„ 
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Figure  1-6:  Sample  Simulation-Space  Knowledge  Documentation. 


1.3.2  Process  Phase  4  -  Design  Conceptual  Model 

In  this  example,  the  conceptual  graph  formalism  was  pre-selected  as  an  arbitrary  choice  of  the  project  Group. 
The  conceptual  model  design  components  were  derived  from  the  formalism.  Table  I- 10  summarizes  the 
conceptual  model  design  components  for  the  conceptual  model  views  of  Figure  1-5,  Figure  1-6  and  Figure  1-7. 
The  artefact  in  Table  I- 10  is  an  example  of  Product  4.1  -  Conceptual  Model  Design. 
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Table  1-10:  Sample  Conceptual  Model  Design  for  IMAGE. 


Component 

Design 

Build 

Conceptual 

Primitives 

Concept 

Blue  Convoy,  Red,  IED,  etc. 

Relation 

Agent,  Object,  Plan,  etc. 

Context 

Attack,  Concept  Group 

Model 

Kinds 

Conceptual  Graphs 

Views 

Mission  Concepts  Inter-Relation 

See  Figure  1-5 

Simulation  Concepts  Hierarchy 

See  Figure  1-6 

Simulation  Specification  for  the  Mission 

See  Figure  1-7 

Formalisms 

Conceptual  Graphs 

Notations 

Conceptual  Graphs 

E 


.Concept  Group:  * 


Blue:  b 


Red:  r 


^concept  Group: : 


Population:  p 


IED:  : 


School  Project:  sp 


Figure  1-7:  Sample  View  from  the  Conceptual  Model  of  a  Simulation. 


1.3.3  Process  Phase  5  -  Build  Conceptual  Model 

Figure  1-7  is  a  conceptual  model  view  illustrating  how  the  scenario  concepts  are  mapped  to  simulation 
concepts  to  describe  the  specification  for  the  simulation.  For  example,  the  Blue  and  Red  concepts  become 
simulation  Agents;  the  Population,  IED  and  School  Project  become  simulation  Patients;  the  Road  Network 
becomes  a  Decor;  and,  a  simulation  Scenario  uses  the  defined  Agents,  Patients  and  Decor.  Table  I- 10  includes 
a  mapping  of  the  conceptual  primitives  and  model  kinds  populated  in  the  conceptual  model. 

The  knowledge  representations  in  Figure  1-5  and  Figure  1-6  can  be  seen  as  other  views  of  the  conceptual  model. 
This  example  is  representative  of  the  reality  where  the  conceptual  model  of  a  simulation  often  relies  on 
conceptual  models  of  the  mission  space  and  the  simulation  space. 
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1.4  COMMUNITY-SPECIFIC  CONCEPTUAL  MODEL  DESIGN  AND 
ARTEFACTS 

The  conceptual  modelers  have  access  to  a  variety  of  design  options.  The  conceptual  model  design  components 
being  strongly  interrelated,  one  design  choice  usually  imposes  constraints  on  the  remaining  component 
options.  This  explains  why  different  communities  have  created  conceptual  model  design  combinations  tailored 
to  their  specific  domains.  The  objective  of  this  example  is  to  present  sample  conceptual  model  artefacts  based 
on  a  community-specific  conceptual  model  design. 

This  example  is  taken  from  the  United  States  OneSAF  Project  [10].  OneSAF  Objective  System  (OOS)  is  a 
composable  Computer  Generated  Forces  (CGF)  simulation  framework. 


1.4.1  Process  Phase  4  -  Design  Conceptual  Model 

The  OneSAF  Group  has  developed  its  own  conceptual  modeling  formalism,  called  CML  [11],  adapted  to 
model  simulations  of  the  tactical  military  mission  space.  The  CML  formalism,  notation  and  conceptual 
primitives  are  illustrated  in  Figure  1-8.  CML  uses  a  color-coded  notation.  Table  1-1 1  presents  the  CML  design 
components. 


Figure  1-8:  The  CML  Formalism,  Notation  and  Conceptual  Primitives. 
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Table  1-11:  Conceptual  Model  Design  for  OneSAF. 


Component 

Design 

Build 

Conceptual 

Primitives 

Element 

Chassis,  Articulation,  Weapon,  Sensor, 

Movement  Adjudicator 

Event 

Activate  Steering,  Fire  Command 

Behavior 

Steering  Behavior,  Maintain  SA,  FDC  Execute 
Fire  Missions 

Characteristic 

Movement  Freedom,  Rotational  Freedom 

Model 

Kinds 

Conceptual  Model  Language 

Views 

Entity 

Entity  Composition  (see  Figure  1-9) 

Common 

Unit  Movement  Control  (see  Figure  I- 10) 

Battlefield  Operating  System 

Tactical  Fire  Direction  Center  (see  Figure  I- 11) 

Formalisms 

CML 

Notations 

CML 

1.4.2  Process  Phase  5  -  Build  Conceptual  Model 

The  OneSAF  conceptual  model  was  built  according  to  the  CML  design.  The  column  “Build”  of  Table  I- 11 
above  includes  a  few  examples  of  how  the  components  have  been  populated.  Figure  1-9  presents  a  sample 
Entity  view  for  the  Entity  Composition.  Figure  I- 10  shows  a  sample  Common  view  representing  the  Unit 
Movement  Control.  Figure  I- 11  is  an  example  of  a  Battlefield  Operating  System  view  for  the  Tactical  Fire 
Direction  Center.  These  artefacts,  all  together,  are  part  of  Product  5.1  -  Conceptual  Model. 
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Figure  1-9:  Sample  View  from  the  OneSAF  Conceptual  Model  Representing  Entity  Composition. 
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Figure  1-10:  Sample  View  from  the  OneSAF  Conceptual 
Model  Representing  Unit  Movement  Control. 
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Figure  1-11:  Sample  View  from  the  OneSAF  Conceptual 
Model  Representing  Tactical  Fire  Direction  Center. 


1.5  ITERATIVE  EVOLUTION  OF  CONCEPTUAL  MODEL  REQUIREMENTS, 
DESIGN  AND  ARTEFACTS 

Producing  preliminary  conceptual  model  artefacts  contributes  to  the  learning  process  and  helps  refining  the 
conceptual  model  requirements.  The  conceptual  model  design  evolves  accordingly  over  several  iterations. 
The  objective  of  this  example  is  to  presents  the  iterative  evolution  of  conceptual  model  requirements  (Process 
Activity  2.1),  design  (Process  Phase  4)  and  artefacts  (Process  Phase  5).  New  requirements  are  challenging  the 
conceptual  model  design  and  new  representation  capabilities  are  incorporated  to  support  the  logical  thinking 
process. 
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This  example  is  taken  from  the  Canadian  KARMA  Project  [11].  KARMA  is  a  simulation  framework  for 
guided-weapon  engagement  simulation  intended  to  be  used  to  develop  countermeasures  and  to  assess  missile 
performance.  The  project  started  from  a  blank  page,  without  any  legacy  simulation  system  to  integrate. 

The  first  conceptual  model  requirement  was  to  allow  the  project  manager  to  represent  the  mission  space 
requirements.  The  informal  view  of  Figure  1-12  was  developed  using  a  MindMap  design  summarized  in 
Table  1-12. 


Figure  1-12:  Sample  View  of  the  KARMA  Conceptual  Model 
Representing  the  Engagement  Mission  Space. 


Table  1-12:  Conceptual  Model  Design  for  KARMA  Engagement  Mission  Space. 


Component 

Design 

Build 

Conceptual 

Primitives 

Entity 

Engagement,  Platform,  Missile,  Autopilot 

Relationship 

Has  a 

Interaction 

Engages,  Triggers,  Senses 

Model  Kinds 

MindMap 

Views 

Component 

Engagement  Mission  Space  (see  Figure  1-12) 

Formalisms 

MindMap 

Notations 

Mind  Manager ®  MindMap 
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The  second  step  involved  the  software  architect  and  the  subject-matter  experts  who  needed  a  conceptual 
model  to  support  the  simulation  architecture  design.  The  conceptual  model  was  used  to  capture  the  subject- 
matter  experts’  knowledge,  to  engineer  the  knowledge  in  order  to  derive  key  concepts  and  to  agree  on  a 
common  understanding  to  be  used  as  the  design  reference.  Figure  1-13  shows  the  final  key  concepts  diagram. 
Several  iterations  of  that  diagram  were  produced  during  working  sessions  before  to  adopt  a  version  satisfying 
the  reusability,  interoperability  and  composability  requirements.  For  example,  an  early  version  of  that  diagram 
included  threat/target  and  red/blue  concepts,  which  was  representative  of  the  subject-matter  experts’  bias. 
The  conceptual  model  proved  to  be  useful  to  get  rid  of  that  bias.  Other  views,  such  as  the  sequence  view  in 
Figure  1-14  and  the  states  view  in  Figure  1-15,  were  used  to  complete  the  representation  and  proof  the  design. 
Table  1-13  summarizes  the  conceptual  model  design  components  based  on  the  UML  notation. 


Figure  1-13:  Sample  View  of  the  KARMA  Conceptual  Model 
Representing  the  Engagement  Key  Concepts. 
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Launcher :  Platform 

:  Weapon 

Taraet  :  Platform 

:  Countermeasure 

Figure  1-14:  Sample  View  of  the  KARMA  Conceptual 
Model  Representing  an  Engagement  Sequence. 


Figure  1-15:  Sample  View  of  the  KARMA  Conceptual 
Model  Representing  an  Engagement  States. 
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Table  1-13:  Conceptual  Model  Design  for  KARMA  Engagement  Key  Concepts. 


Component 

Design 

Build 

Conceptual 

Primitives 

Key  Concept  (Class) 

Physical  Environment ,  Platform,  Weapon, 
Countermeasure 

Property  (Attribute) 

Signature,  Dynamics,  Equipments, 

Atmosphere 

Interaction 

Detect,  Launch,  Track,  Deploy,  Counter, 

Exist  In,  Influence 

Instance 

Launcher,  Target 

States 

Target  Acquired,  LockOn,  Launched 

Model  Kinds 

Class  Diagram 

Sequence  Diagram 

State  Diagram 

Views 

Logicals 

Engagement  Key  Concepts  (see  Figure  1-13) 

Engagement  Sequence  (see  Figure  1-14) 

Engagement  States  (see  Figure  1-15) 

Formalisms 

UML 

Notations 

UML 

The  conceptual  model  further  evolved  to  allow  the  software  developers  to  implement  the  simulation  architecture. 
The  engagement  concepts  were  expressed  in  the  object-oriented  formalism  as  shown  in  Figure  1-16.  Simulation 
space  concepts,  such  as  the  scheduler  and  logger  mechanisms,  were  introduced  as  represented  in  Figure  1-17. 
Additional  primitives  (classes,  attributes,  methods,  etc.)  completed  the  model  to  allow  the  automatic  generation 
of  a  C++  implementation  from  the  model. 
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Figure  1-16:  Sample  View  of  the  KARMA  Conceptual  Model  Representing 
an  Engagement  in  the  Object-Oriented  Formalism. 


Figure  1-17:  Sample  View  of  the  KARMA  Conceptual  Model  Including  Simulation 
Space  Concepts  and  Implementation-Related  Conceptual  Primitives. 
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The  complete  conceptual  allows  for  the  complete  traceability  from  needs  to  requirements  to  specification  to 
implementation.  Each  stakeholder  is  leveraging  the  conceptual  model  for  his  purpose. 


1.6  CONCLUSION 

This  annex  presented  a  limited  number  of  examples  complementing  the  best-practice  guidance.  In  the  interim 
of  a  standard  conceptual  model  specification,  each  enterprise  has  to  specify  its  own  conceptual  modeling 
process  and  conceptual  model  products,  to  a  level  down  to  actual  templates  if  required.  The  proposed 
guidance  should  serve  as  reference  and  the  examples,  as  inspiration.  Every  customization  of  the  guidance  will 
contribute  to  the  science  of  conceptual  modeling  and  will  bring  valuable  experience  to  the  standardization 
table. 
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Term 

DEFINITION  or  COMMENT 

REFERENCE 

Abstract 

(Adjective) 

4. a)  Withdrawn  or  separated  from  matter,  from  material  embodiment, 
from  practice,  or  from  particular  examples.  Opposed  to  concrete. 

OED 

Abstraction 

(Noun) 

Denotes  the  essential  characteristics  of  an  object  that  distinguish  it  from 
all  other  kinds  of  objects  and  thus  provide  crisply  defined  conceptual 
boundaries,  relative  to  the  perspective  of  the  user. 

M&S  Glossary, 
DMSO  Survey 
of  Semi- 
Automated 

Forces 

Abstraction 
(Noun/V  erb) 

1)  The  process  of  selecting  the  essential  aspects  of  simuland  to  be 
represented  in  a  model  or  simulation  while  ignoring  those  aspects  that 
are  not  relevant  to  the  purpose  of  the  model  or  simulation.  2)  The  set  of 
elements  produced  by  this  process.  3)  The  act  or  process  of  separating 
the  inherent  qualities  or  properties  of  something  from  the  actual  physical 
object  or  concept  to  which  they  belong.  4)  A  product  of  this  process,  as  a 
general  idea  or  word  representing  a  physical  concept. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary 

Abstraction 

(Noun) 

An  intuitive  technique  transforming  the  essential  features  of  a  real 
system  into  a  different  form. 

Jake  Borah 
Tutorial 

Abstraction 

(Noun) 

Denotes  the  essential  characteristics  of  an  object  that  distinguish  it  from 
all  other  kinds  of  objects  and  thus  provide  crisply  defined  conceptual 
boundaries,  relative  to  the  perspective  of  the  user. 

OED 

Abstraction 

(Verb) 

Generalization  of  a  concept,  idea,  or  symbol  versus  specialization. 

Abstraction 

(Verb) 

Process  of  generalization  by  reducing  the  information  content  of  a 
concept  3264  or  an  observable  phenomenon  typically  in  order  to  retain 
only  information  3265  which  is  relevant  for  a  particular  purpose. 

M&S  Glossary 

Abstraction 

(Verb) 

The  act  of  process  of  separating  in  thought,  of  considering  a  thing 
independently  of  its  associations;  or  a  substance  independently  of  its 
attributes;  or  an  attribute  or  quality  independently  of  the  substance  to 
which  it  belongs. 

OED 

Abstractness 

Degree  of  abstraction. 

Abstractness 

Relates  to  the  degree  to  which  the  conceptual  model  abstracts  or 
symbolizes  the  referent. 

Text 

Accessibility 

The  ease  of  approaching,  entering,  obtaining,  or  using. 

DoD  “Data 
Quality 

Assurance 

Procedures”, 

DoD  8320. 
l-M-3 
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DEFINITION  or  COMMENT 

REFERENCE 

Accreditation 

Official  acceptance  or  certification  that  a  model,  the  data  for  a 
simulation  or  a  simulation  is  suitable  for  a  specific  purpose  or 
application. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Accuracy 

Correctly  know  in  quantity. 

Accuracy 

The  degree  to  which  a  parameter  or  variable  or  set  of  parameters  or 
variables  within  a  model  or  simulation  conform  exactly  to  reality  or  to 
some  chosen  standard  or  referent.  See  resolution,  fidelity,  and  precision. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Actions 

1)  The  process  or  conditions  of  acting  or  doing  (in  the  widest  sense),  the 
exertion  of  energy  or  influence;  working,  agency,  operation,  a.  Of 
persons.  (Distinguished  from  passion,  from  thought  or  contemplation , 
from  speaking  or  writing)  b.  Of  things.  (Distinguished  from  inaction, 
repose)  quantity  of  action ,  in  Physics:  The  momentum  of  a  body 
multiplied  into  the  time.  3)  a.  A  thing  done,  a  deed,  not  always 
distinguished  from  ACT,  but  usually  viewed  as  occupying  some  time  in 
doing,  and  in  pi.  referred  to  habitual  or  ordinary  deeds,  the  sum  of  which 
constitutes  conduct. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary 

Actions 

Elementary  components  of  behaviour  of  an  entity,  object  or  system. 

Activity 

A  task  that  consumes  time  and  resources  and  whose  performance  is 
necessary  for  a  system  to  move  from  event  to  the  next. 

“IEEE  Standard 
Glossary  of 
Modeling  and 
Simulation 
Technology”, 
IEEE  Std  610. 
3-1989,  nd 

Activity  Model 

A  model  of  the  processes  that  make  up  a  functional  activity  showing 
inputs,  outputs,  controls,  and  mechanisms  through  which  the  processes 
of  the  functional  activity  are  or  will  be  conducted. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M 

Actor 

The  subject  (perpetrator,  agent)  of  action. 

Text 

Adaptability 

The  quality  of  being  adaptable;  capacity  of  being  adapted  or  of  adapting 
oneself;  potential  fitness  for  one  or  another  intended  purpose. 

(See  Tailorability) 

Aggregation 

The  ability  to  group  items,  whether  entities  or  processes,  while 
preserving  the  effects  of  item  behavior  and  interaction  while  grouped. 

A  relationship  between  objects  in  the  data  model  where  one  object 
contains  other  objects.  (See  Disaggregation). 

DoD  M&S 
Master  Plan, 

DoD  5000-59-P, 
SEDRIS 

Glossary 

Aggregation 

(Noun) 

Also  Aggregate 

A  whole  composed  of  many  particulars;  a  mass  formed  by  the  union  of 
distinct  particles;  a  gathering,  assemblage,  collection. 

OED 
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Term 

DEFINITION  or  COMMENT 

REFERENCE 

Aggregation 

(Verb) 

The  action  or  process  of  collecting  particles  into  a  mass,  or  particulars 
into  a  whole;  or  of  adding  one  particle  to  an  amount;  collection, 
assemblage,  union. 

OED 

Analytical  Frame 

In  this  context  -  one  or  another  way  of  looking  at  the  world.  Alternatives 
of  such  frames  include  for  instance:  ontology,  systems  engineering, 
software  engineering,  and  knowledge  management;  together  with  a  wide 
variety  of  tools  and  techniques  for  pursuing  explication  of  each  frame, 
such  as  model  driven  architecture,  Knowledge  Acquisition  /  Knowledge 
Engineering  (KA/KE)  assets,  systems  engineering  tools,  etc. 

Text 

Architecture 

The  structure  of  components  in  a  program  or  system,  their 
interrelationships,  and  the  principles  and  guidelines  governing  their 
design  and  evolution  over  time. 

DoD,  M&S 
Master  Plan, 

DoD  5000-59-P 

Artefact 

All  or  part  of  a  work-product  generated  by  the  Task  Group  or  by  M&S 
conceptual  model  practitioners  in  generating,  and  documenting  a 
simulation  conceptual  model. 

Artefact 

.  A)  n.  Anything  made  by  human  art  and  workmanship;  an  artificial 
product.  In  Archaol  applied  to  the  rude  products  or  original  work  mans 
hip  as  distinguished  from  natural  remains.  B)  In  technical  and  medical 
use,  a  product  or  effect  that  is  not  present  in  the  natural  state  (of  an 
organisms,  etc.)  but  occurs  during  or  as  a  result  of  investigation  or  is 
brought  about  by  some  extraneous  agency. 

OED 

Attribute 

In  object  oriented  analysis,  (and  simulation  representation)  the  set  of 
characteristics  of  some  class  inherited  by  its  specializations  and 
instances  -  which  together  with  its  behaviours  and  relationships, 
completely  describes  the  state  of  an  object  of  system  of  object  entities. 

Attribute 

.  1)  A  quality  or  character  ascribed  to  any  person  or  thing,  one  which  is  in 
common  estimation  or  usage  assigned  to  him;  hence,  sometimes ,  an 
epithet  or  appellation  in  which  the  quality  is  ascribed.  4)  A  quality  or 
character  considered  to  belong  to  or  be  inherent  in  a  person  or  thing;  a 
characteristic  quality,  c.  in  Logic,  that  which  may  be  predicated  of  any 
thing;  a  quality,  mode  of  existence,  affection;  strictly  an  essential  and 
permanent  quality. 

OED 

Attribute 

1)  A  property  or  characteristic  of  one  or  more  entities  or  objects 
(e.g.,  COLOR,  WEIGHT,  SEX).  2)  A  property  inherent  to  an  entity  or 
associated  with  that  entity  for  database  purposes.  3)  A  quantifiable 
property  of  an  object  (e.g.,  the  color  of  a  building  or  the  width  of  a 
road). 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M, 
SEDRIS 

Glossary 

Authoritative  Data 
Source 

A  data  source  whose  products  have  undergone  producer  data 
verification,  validation,  and  certification  activities. 

The  Fidelity 

ISG  Glossary 

Authoritative 

Representation 

Models,  algorithms,  and  data  that  have  been  developed  or  approved  by 
a  source  which  has  accurate  technical  knowledge  of  the  entity  or 
phenomenon  to  be  modeled  and  its  effects. 

The  Fidelity 

ISG  Glossary 
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Term 

DEFINITION  or  COMMENT 

REFERENCE 

Behavior 

The  means  an  actor  performs  or  uses  to  actuate  events. 

Text 

Behavior 

1)  For  a  given  object,  how  attribute  value  changes  affect  or  are  affected 
by  the  attribute  value  changes  of  the  same  or  other  objects.  2)  The  way 
in  which  a  system  responds  to  stimuli  over  time. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Best-Practice 

Standard 

Guidance  containing  prescriptive  instructions  of  such  quality  that  is  not 
exceeded  elsewhere. 

Business 

Ecosystem 

The  environment  including  entities,  processes,  and  active  agents 
constituting  a  universe  of  operations  for  one  or  another  set  of  business 
transactions  or  operations.  (See  Economic  Ecosystem) 

CASE 

Computer  Aided  Systems  Engineering. 

Class 

A  description  of  a  group  of  objects  with  similar  properties,  common 
behavior,  common  relationships,  or  common  semantics. 

The  Fidelity 

ISG  Glossary 

Class  Hierarchy 

A  specification  of  a  class,  sub-class,  or  “is-a-kind-of”  relationship 
between  object  classes  in  a  given  domain. 

The  Fidelity 

ISG  Glossary 

COTS 

A  good  that  is  available  in  the  private  sector  market,  normally  at  a  price 
established  by  supply  and  demand  and  distributed  under  proprietary 
licensing. 

Commonality 

Consistency  between  or  among  entities  of  processes  facilitating  the 
capability  to  communicate,  influence  one  another,  and  generally 
cooperate  to  some  intended  constructive  purpose. 

Completeness 

Degree  to  which  a  work-product  exhausts  its  requirements.  All  needs, 
constraints  and  policies  are  covered  by  one  or  more  requirements,  or  all 
requirements  are  covered  by  the  content  of  the  consequent  conceptual 
model  product. 

Composability 

Capacity  or  suitability  to  be  subject  to  composition. 

Composition 

Act  of  combining  elements  or  components  into  an  intended  aggregate 
entity  or  system. 

Computational 

Model 

A  model  consisting  of  well-defined  procedures  that  can  be  executed  on  a 
computer  (e.g.,  a  model  of  the  stock  market,  in  the  form  of  a  set  of 
equations  and  logic  rules). 

“IEEE 

Standard 

Glossary  of 

M&S 

Terminology”, 
IEEEStd 
610.3-1989,  nd. 

Computer  Science 

Computer  Science  or  Computing  Science  (abbreviated  CS)  is  the  study 
of  the  theoretical  foundations  of  information  and  computation  and  of 
practical  techniques  for  their  implementation  and  application  in 
computer  systems. 

http://en.wikipe 

dia.org/wiki/Co 

mputerscience 
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Term 

DEFINITION  or  COMMENT 

REFERENCE 

Computer 

Simulation 

A  dynamic  representation  of  a  model,  often  involving  some  combination 
of  executing  code,  control/display  interface  hardware,  and  interfaces  to 
real-world  equipment. 

The  Fidelity 

ISG  Glossary 

Computer 

Software 

A  set  of  computer  programs,  procedures,  and  associated  documentation 
concerned  with  the  operation  of  a  data  processing  system  (e.g.,  compilers, 
library  routines,  manuals,  and  circuit  diagrams);  software. 

The  Fidelity 

ISG  Glossary 

Concept 

Roughly  equivalent  to  the  “idea  in  the  mind”  resulting  from  a  perception 
or  the  mental  processing  of  perceptions  and  existing  ideas. 

David  Hume 

Concept 

In  normal  language,  concept  may  mean  “something  out  there  in  the 
world”  or  alternatively  and  inconsistently,  “an  entity  within  one’s  head” 
Formally,  a  concept  may  be  defined  as:  “A  mental  representation  that 
can  serve  as  the  meaning  of  a  linguistic  expression.” 

Ray  Jackendoff 

Concept 

Concepts  are  the  Materials  of  reason  and  knowledge. 

John  Locke 

Concept 

“...  concepts  are  [the]  constituents  of  thought.”  “Conceptions  explain 
epistemological  facts  (e.g.,  how  we  judge  that  something  is  a  dog),  while 
concepts  explain  meta-physical  facts  (e.g.,  what  makes  something  a 
dog).”  “. . .  concepts  just  are  perceptual  detection  mechanisms.” 

“Concepts  are  prototypes,  where  prototypes  are  perceptually  derived 
representations  that  can  be  recruited  by  working  memory  to  represent  a 
category.”  Therefore,  “[i]f  concepts  are  prototypes,  thinking  is  a 
simulation  process.” 

Jesse  Prinz 

Concept 

An  abstract  idea  or  a  mental  symbol,  typically  associated  with  a 
corresponding  representation  in  language  or  symbology  that  denotes  all 
of  the  objects  in  a  given  category  or  class  of  entities,  interactions, 
phenomena,  or  relationships  between  them. 

Text 

Conceptual 
(Model)  Primitives 

Atomic  components  from  which  conceptual  model  specifications  are 
composed.  (See  Primitives) 

Text 

Conceptual 

Category 

One  of  “. . .  a  small  set  of  major  ontological  categories  (or  conceptual 
‘parts  of  speech’)  such  as  Thing,  Event,  State,  Place,  Path,  Property  and 
Amount.” 

Ray  Jackendoff 

Conceptual 

Constituent 

The  major  units  of  conceptual  structure,  each  of  which  belongs  to  a 
small  set  of  conceptual  categories. 

Ray  Jackendoff 

Conceptual  Model 

Model  that  abstractly  represents  a  referent. 

Conceptual  Model 

A  simulation  developer’s  method  of  translating  modeling  requirements 
into  a  detailed  design  framework- [use]. 

Dale  Pace 

Conceptual  Model 

1)  A  description  of  the  content  and  internal  representations  that  are  the 
users’  and  developer’s  combined  concept  of  the  model  including  logic 
and  algorithms  and  explicitly  recognizing  assumptions  and  limitations. 

2)  An  implementation-independent  description  of  the  content  and 
internal  representations  that  represent  the  sponsor’s,  user’s  and 
developer’s  combined  concept  of  the  system  or  simulation  under 
development  including  logic,  architecture,  algorithms,  available  data  and 
explicitly  recognising  assumptions  and  limitations. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 
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Conceptual  Model 
Characteristic 

Attributes  or  qualia  of  a  conceptual  model,  such  as  Quality,  utility, 
formality,  abstractness,  etc. 

Conceptual  Model 
Components 

Parts  comprising  a  conceptual  model,  such  as  conceptual  primitive, 
model  kind,  view,  formalism,  notation,  etc. 

Conceptual  Model 
Design 

See  ‘Design’  and  Section  6.2.8. 

Text 

Conceptual  Model 
of  (a)  Simulation 

The  conceptual  model  of  the  Mission  Space  integrated  with  the 
conceptual  model  of  Simulation  Space. 

Text 

Conceptual  Model 
of  the  Mission 

Space  (CMMS) 

First  abstraction  of  the  real  world  that  serves  as  a  frame  of  reference  for 
simulation  development  by  capturing  the  basic  information  about 
important  entities  involved  in  any  mission  and  their  key  actions  and 
interactions;  simulation-neutral  view  of  those  entities,  actions,  and 
interactions  occurring  in  the  real  world. 

The  Fidelity 

ISG  Glossary 

Conceptual  Model 
Quality 

The  totality  of  features  and  characteristics  of  a  conceptual  model  that 
bear  on  its  ability  to  satisfy  stated  or  implied  needs. 

Conceptual  Model 
Requirements 

See  ‘Requirements’  and  Section  6.2.5. 

Text 

Conceptual  Model 
Space 

Domain  to  which  conceptual  model  representation  refers. 

Conceptual 

Schema 

A  descriptive  representation  of  data  and  data  requirements  that  supports 
the  “logical”  view  or  data  administrator’s  view  of  the  data  requirement. 
This  view  is  represented  as  a  semantic  model  of  the  information  that  is 
stored  about  objects  of  interest  to  the  functional  area.  This  view  is  an 
integrated  definition  of  the  data  that  is  unbiased  toward  any  single 
application  of  data  and  is  independent  of  how  the  data  is  physically 
stored  or  accessed. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M 

Conceptual 

Scheme/Schema 

A  self-consistent  style  of  abstraction  and  associated  conceptual 
categories  and  primitives  or  constituents  employed  in  personal  or 
enterprise  perception  and  descriptive  communication. 

W.V.  Quine 

Conceptualization 

“. . .  an  abstract  simplified  view  of  the  world.”  (See  Concept) 

Dragan  Gasevic 

Consistency 

Degree  to  which  components  of  a  whole  are  congruent  or  are  similarly 
conceived,  configured,  and  expressed.  Lack  of  incongruity  or  logical 
incompatibility  among  such  components. 

Consumer 

Role  position  designating  person  or  organization  that  will  put  the 
conceptual  model  to  use  in  order  to  implement  an  executable  model  to 
satisfy  the  sponsor’s  needs. 

Consumer 

(Analyst) 

1)  Understanding  operational  issues  and  mission  context.  2)  Producing 
relevant  analysis  products. 

Text 

Consumer  (Model 
Implementer) 

1)  Understanding  operational  issues  and  mission  context. 

2)  Implementation  of  simulation  model. 
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DEFINITION  or  COMMENT 

REFERENCE 

Consumer  (Model 

Implementer) 

(cont’d) 

3)  Verification  of  simulation  model  compliance  with  conceptual  model. 

Consumer 
(Training  System 
Developer) 

1)  Understanding  operational  issues  and  mission  context.  2)  Producing 
adequate  training  environment. 

Text 

Consumption 

Process  of  using  products  in  order  to  satisfy  needs  and  desires  (self¬ 
generated  or  imposed;  real  or  imagined)  so  that  the  products  are  used  up, 
transformed,  or  deteriorated  in  such  a  manner  as  not  to  be  either  reusable 
or  recognizable  in  their  original  form.  In  economics,  the  final  using  up 
of  goods  and  services.  The  term  excludes  the  use  of  intermediate 
products  in  the  production  of  other  goods  (e.g.,  the  purchase  of 
buildings,  machinery,  or  software  by  an  enterprise).  Also,  Consumption 
can  be  viewed  as  a  basically  subjective  phenomenon,  with  individual  or 
organizational  utility,  or  satisfaction,  having  primary  importance  in  the 
valuation  of  the  product(s)  consumed. 

Metrics  for 

M&S 

Investments 

Consumption 

The  process  of  expending  money  by  a/an  organization/individual/ 
department/entity/project  that  does  not  result  in  an  increase  of  assets. 

Metrics  for 

M&S 

Investments 

Control 

Defines  what  can  occur  within  an  activity.  Constraint  upon  behaviour  of 
relevant  entity. 

Text 

Correctness 

The  property  of  an  artefact  (e.g.,  a  conceptual  model)  to  comply  with 
formal  rules  and  bodies  of  reference  information  for  its  representation 
and  for  the  transformation  of  its  representation  into  another  one. 

Correctness 

All  needs,  constraints  and  policies  have  been  interpreted  as  the  sponsor 
intended. 

Correctness 

Degree  to  which  the  Conceptual  Model  implementation  is  free  of  error 
and  of  sufficient  precision. 

Cost 

“The  amount  or  equivalent  paid  or  charged  for  something”  or  the  “loss 
or  penalty  incurred  especially  in  gaining  something”  (http://www.mer 
riam-webster.com/dictionary/cost).  Normally,  the  value  of  a  liquid  asset 
or  cash  that  must  be  paid  for  a  good  or  service.  (See  Value) 

Cost  Benefit 

A  method  of  reaching  economic  decisions  by  comparing  the  costs  of 
doing  something  with  its  benefits.  Especially  useful  when  contributing 
factors  are  inherently  monetary  -  can  be  complex  when  the  decision 
being  contemplated  involves  some  cost  or  benefit  for  which  there  is  no 
market  price  or  which,  because  of  an  externality,  is  not  fully  reflected  in 
the  market  price. 

Credibility 

Quality  of  being  credible,  i.e.,  capable  of  being  believed;  believable. 

OED 

Criteria 

The  value  of  a  variable  or  parameter  against  which  some 
commensurable  measured  or  observed  value  relevant  to  an  object  or 
process  of  interest  can  be  compared  for  purposes  of  evaluation  (singular, 
criterion). 
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Custodian 

The  person  or  organization  that  ensures  that  the  repository  is  maintained 
and  policies  adhered  to. 

Custodian 

Provide  services  for  effective  reuse  of  available  knowledge  and 
Conceptual  Model  components. 

Customer 

The  buyer  of  a  good  or  service,  sometimes,  but  not  necessarily  the  also 
the  consumer  -  user. 

Customer 

Buyer  of  some  good  or  service.  Sometimes,  in  prospectus,  having 
bought  in  the  past  or  considered  likely  to  buy  in  the  future.  Customers 
normally  have  discretionary  choice  whether  to  buy  a  good  or  service, 
but  normally  do  not  effect  price  in  public  sector  markets.  Customers  in 
government  economic  transactions  normally  negotiate  with  seller  to 
control  price,  rate,  quality,  and  risk.  Influence  of  customers  in  private 
sector  markets  seldom  persists  beyond  the  sales  event  except  insofar  as 
warranty  or  goodwill  considerations  pertain. 

Metrics  for 

M&S 

Investments 

Data 

1)  A  representation  of  facts,  concepts,  or  instructions  in  a  formalized 
manner  suitable  for  communication,  interpretation,  or  processing  by 
humans  or  by  automatic  means.  2)  Assumed,  given,  measured,  or 
otherwise  determined  facts  or  propositions  used  to  draw  a  conclusion 
or  make  a  decision. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M, 
Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Data  Architecture 

The  framework  for  organizing  and  defining  the  interrelationships  of  data 
in  support  of  an  organization’s  missions,  functions,  goals,  objectives, 
and  strategies.  Data  architectures  provide  the  basis  for  the  incremental, 
ordered  design  and  development  of  databases  based  on  successively 
more  detailed  levels  of  data  modeling. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M 

Data  Dictionary 

A  specialized  type  of  database  containing  Meta  data  that  is  managed  by 
a  data  dictionary  system;  a  repository  of  information  describing  the 
characteristics  of  data  used  to  design,  monitor,  document,  protect,  and 
control  data  in  information  systems  and  databases. 

The  Fidelity 

ISG  Glossary 

Data  Model 

1)  The  user’s  logical  view  of  the  data  in  contrast  to  the  physically  stored 
data,  or  storage  structure.  2)  A  description  of  the  organization  of  data  in 
a  manner  that  reflects  the  information  structure  of  an  enterprise. 

3)  A  description  of  the  logical  relationships  between  data  elements 
where  each  major  data  element  with  important  or  explicit  relationships  is 
captured  to  show  its  logical  relationship  to  other  data  elements. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M, 
SEDRIS 

Glossary 

Data  Repository 

A  specialized  database  containing  information  about  data  such  as 
meaning,  relationships  to  other  data,  origin,  usage,  and  format,  including 
the  information  resources  needed  by  an  organization. 
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REFERENCE 

Data 

Representation 

1)  A  format  used  to  describe  some  type  of  data.  2)  A  variety  of  forms 
used  to  describe  a  terrain  surface,  the  features  placed  on  the  terrain,  the 
dynamic  objects  with  special  3-D  model  attributes  and  characteristics, 
the  atmospheric  and  oceanographic  features,  and  many  other  forms  of 
data. 

Report  from 
the  Fidelity 
Implementation 
Study  Group, 
SEDRIS 
Glossary,  29 

June  1998 

Data  Source 

1)  An  organization  or  subject-matter  expert  who,  because  of  either 
mission  or  expertise,  serves  as  a  data  producer.  2)  A  publication  that 
serves  as  an  authoritative  source  of  data  used  in  a  model  or  simulation. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Data  Validation 

The  documented  assessment  of  data  by  subject  area  experts  and  its 
comparison  to  known  values. 

DoD,  “M&S 
Master  Plan”, 
DoD  5000-59-P 

Data  Verification 

Data  producer  verification  is  the  use  of  techniques  and  procedures  to 
ensure  that  data  meets  constraints  defined  by  data  standards  and  business 
rules  derived  from  process  and  data  modeling.  Data  user  verification  is 
the  use  of  techniques  and  procedures  to  ensure  that  data  meets  user 
specified  constraints  defined  by  data  standards  and  business  rules 
derived  from  process  and  data  modeling,  and  that  data  are  transformed 
and  formatted  properly. 

DoD,  “M&S 
Master  Plan”, 
DoD  5000-59-P 

Deaggregation 

(Disaggregation) 

The  ability  to  separate  grouped  items,  whether  entities  or  processes, 
while  preserving  the  effects  of  item  behavior  and  interaction  whether 
grouped  or  separated. 

The  Fidelity 

ISG  Glossary 

Design  (noun) 

1 .  a.  A  plan  or  scheme  conceived  in  the  mind  and  intended  for  subsequent 
execution;  the  preliminary  conception  of  an  idea  that  is  to  be  carried  into 
effect  by  action. 

OED 

Design  (noun) 

2.  The  purposeful  or  inventive  arrangement  of  parts  or  details. 

The  free 

Dictionary, 

http://www.thef 

reedictionary.co 

m/design 

Design  (noun) 

The  arrangement  of  elements  or  details  in  a  product  or  work  of  art. 

http://www.mer 

riam-webster. 

com/dictionary/ 

design?show=l 

&t=130340359 

0 

Design  (noun) 

A  plan  or  drawing  produced  to  show  the  look  and  function  or  workings 
of  a  building,  garment,  or  other  object  before  it  is  built  or  made. 

Wikipedia 
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Design  (n.) 

The  visual  characteristics  embodied  in  or  applied  to  an  article  [in  patent 

http://www.uspt 

law]. 

o.gov/web/offic 

es/pac/mpep/do 

cuments/1500_ 

1502.htm 

Detail 

l.a.  The  dealing  with  matters  item  by  item,  detailed  treatment;  attention 
to  particulars  ...  i.e.,  to  deal  or  treat  with  a  thing  in  its  individual 
particulars. 

OED 

Detail 

Having  to  do  with  precision  of  identification  or  description. 

Developers 

Agents  responsible  for  development  of  conceptual  models. 

Text 

Disaggregate 

Activity  that  decomposes  an  aggregated  entity  into  multiple  entities 

Report  from 

representing  its  components. 

the  Fidelity 
Implementation 
Study  Group 

Domain 

3. a  .fig.  A  sphere  of  thought  or  action;  field  province,  scope  of  a 
department  of  knowledge,  etc. 

OED 

Domain 

The  physical  or  abstract  space  in  which  the  [relevant]  entities  and 

The  Fidelity 

processes  operate. 

ISG  Glossary 

Domain  Analysis 

The  process  of  identifying,  acquiring  and  evaluating  the  information 

Report  from 

related  to  a  problem  domain  to  be  used  in  specifying  and  constructing 

the  Fidelity 

a  model  or  simulation. 

Implementation 
Study  Group 

Domain  of 
Knowledge 

Knowledge  related  to  a  given  domain. 

Domain  Ontology 

The  ontology  of  a  given  domain. 

Economic 

An  economic  community  supported  by  a  foundation  of  interacting 

Ecosystems 

organizations  and  individuals— the  organisms  of  the  business  world. 

This  economic  community  produces  goods  and  services  of  value  to 
customers,  who  are  themselves  members  of  the  ecosystem.  The  member 
organizations  also  include  suppliers,  lead  producers,  competitors,  and 
other  stakeholders.  Over  time,  they  co-evolve  their  capabilities  and 
roles,  and  tend  to  align  themselves  with  the  directions  set  by  one  or  more 
central  companies.  Those  companies  holding  leadership  roles  may 
change  over  time,  but  the  function  of  ecosystem  leader  is  valued  by  the 
community  because  it  enables  members  to  move  toward  shared  visions 
to  align  their  investments  and  to  find  mutually  supportive  roles. 

(Source:  Predators  and  Prey:  A  New  Ecology  of  Competition,  by 

James  F.  Moore,  Harvard  Business  Review,  May/June  1993). 
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Emulate 

To  represent  a  system  by  a  model  that  accepts  the  same  inputs  and 
produces  the  same  outputs  as  the  system  represented  (e.g.,  to  emulate 
an  8-bit  computer  with  a  32-bit  computer). 

“IEEE 

Standard 

Glossary  of 

M&S 

Terminology”, 
IEEE  Std  610- 
3-1989,  nd 

Encapsulation 

The  process  of  hiding  the  details  of  an  object  that  do  not  contribute  to  its 
essential  characteristics. 

The  Fidelity 

ISG  Glossary 

Enterprise 

One  or  more  organizations  under  common  control.  Generally  refers  to 
the  broadest  scope  of  organizations  and  operational  process  relevant  to 
the  subject  discussion  rather  than  to  individual  components  thereof. 

Text 

Enterprise 

Concepts-of- 

Operations 

The  single,  unified  Concept  of  Operations  (CONOPS)  whereby  the 
multiple  organizations  comprising  an  enterprise  ensemble  cooperate. 
Enterprise  CONOPS  often  entail  more  formality,  and  systematic 
consensus-based  collaboration,  as  well  as  more  explicitly  coordinated 
and  documented  modeling  and  simulation  development  and  employment 
than  is  common  in  more  parochial  contextual  environments. 

Enterprise  Context 

The  operational  or  environmental  context  at  which  enterprise 
considerations  agents,  relationships,  and  transactions  are  relevant. 

Enterprise  Model 

An  information  model(s)  that  presents  an  integrated  top-level 
representation  of  processes,  information  flows,  and  data. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M 

Enterprise-Based 

Operations,  process,  or  work-products  typically  tailored-to  or  used-in  or 
generated- from  enterprise-style  circumstances. 

Entity 

A  distinguishable  person,  place,  thing,  event  or  concept  about  which 
information  is  kept.  Something  that  exists  as  a  particular  and  discrete 
unit. 

The  Fidelity 

ISG  Glossary 

Entity/Entities 

A  thing.  Usually  an  element  or  component  part  of  the  mission  space  or 
simulation  space  representation  domain  of  a  conceptual  model  of  a 
simulation.  Note  that  entity  is  distinguished  throughout  the  document 
from  ‘object’,  whose  specific  connotations  in  object-oriented  analysis, 
and  object-based  software  development  have  been  intentionally  avoided. 

Entity  Relationship 
Diagram  (ERD) 

A  graphic  representation  of  a  data  model. 

The  Fidelity 

ISG  Glossary 

Epistemology 

The  theory  or  science  of  the  method  or  grounds  of  knowledge. 

OED 

Evaluator 

Person  or  organization  that  validates  the  conceptual  models,  ensuring 
validity  of  Conceptual  Model  and  compliance  with  requirements. 

Event 

Occurrence  of  the  change  of  value  of  one  or  another  of  the  ‘state 
variables’  of  the  simulation  representation  information  set. 
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Event  (cont’d) 

In  ‘discrete-event  simulation’  techniques,  events  occupy  no  duration  but 
have  as  attributes  the  value  of  the  simulation  time  at  which  the  related 
represented  state-change  occurred. 

Event 

An  action  composed  of  activities. 

Text 

Event 

A  change  in  an  object  attribute  value,  an  interaction  between  objects, 
an  instantiation  of  a  new  object,  or  a  deletion  of  an  existing  object  that 
is  associated  with  a  particular  point  on  the  federation  time  axis.  An 
individual  stimulus  from  one  object  to  another  at  a  particular  point  of 
time. 

The  Fidelity 

ISG  Glossary 

Executability 

Ability  of  prescriptive  guidance  to  be  executed  or  accomplished. 
Alternatively,  the  ability  of  a  computer  program,  algorithm  or  simulation 
to  be  made  to  operate  according  to  program  guidance  and  consistent 
with  expectation. 

Expressiveness 

Efficiency  of  communication  of  information  in  an  expression. 

Information  density  combined  with  readability  or  correct  interpretation. 

Extensibility 

The  ability  of  a  data  structure  to  accommodate  additional  values  or 
iterations  of  data  over  time  without  impacting  its  initial  design. 

DoD,  “Data 
Quality 

Assurance 

Procedures”, 

DoD  8320. 1-M- 
3,  DoD,  “Data 
Administration 
Procedures”, 

DoD  8320. 1-M 

External  Schema 

A  logical  description  of  an  enterprise  that  may  differ  from  the 
conceptual  schema  upon  which  it  is  based  in  that  some  entities, 
attributes,  or  relationship  may  be  omitted,  renamed,  or  otherwise 
transformed. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M 

Federation  Object 
Model  (FOM) 

An  identification  of  the  essential  classes  of  objects,  object  attributes, 
and  object  interactions  that  are  supported  by  a  High  Level  Architecture 
federation.  In  addition,  optional  classes  of  additional  information  may 
also  be  specified  to  achieve  a  more  complete  description  of  the 
federation  structure  and/or  behavior. 

The  Fidelity 

ISG  Glossary 

Fidelity 

Accuracy  or  correctness  of  representation  -  the  degree  to  which  the 
representation  conforms  in  resemblance  to  the  referent. 

Fidelity 

1)  The  degree  to  which  a  model  or  simulation  reproduces  the  state  and 
behavior  of  a  real-world  object  or  the  perception  of  a  real-world  object, 
feature,  condition,  or  chosen  standard  in  a  measurable  or  perceivable 
manner;  a  measure  of  the  realism  of  a  model  or  simulation;  faithfulness. 
Fidelity  should  generally  be  described  with  respect  to  the  measures, 
standards  or  perceptions  used  in  assessing  or  stating  it.  See  accuracy, 
sensitivity,  precision,  resolution,  repeatability,  model/simulation 
validation. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 
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REFERENCE 

Fidelity  (cont’d) 

2)  The  methods,  metrics,  and  descriptions  of  models  or  simulations  used 
to  compare  those  models  or  simulations  to  their  real-world  referents  or 
to  other  simulations  in  such  terms  as  accuracy,  scope,  resolution,  level  of 
detail,  level  of  abstraction  and  repeatability.  Fidelity  can  characterize  the 
representations  of  a  model,  a  simulation,  the  data  used  by  a  simulation 
(e.g.,  input,  characteristic  or  parametric),  or  an  exercise.  Each  of  these 
fidelity  types  has  different  implications  for  the  applications  that  employ 
these  representations. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Formal  Conceptual 
Model 

A  conceptual  model  with  the  following  attributers  or  consequences  of 

formality: 

-  Unambiguous  description  of  model  structure  separated  from  software 
implementation. 

-  Useful  once  users  and  colleagues  understand  informal  model  and  want 
more  detail. 

-  Used  as  an  aid  to  detect  omissions  and  inconsistencies  and  resolve 
ambiguities  inherent  in  informal  models. 

Jake  Borah 
Tutorial 

Formal  Language 

In  logic,  a  set  of  symbols  together  with  a  set  of  formation  rules  that 
designate  certain  sequences  of  symbols  as  well-formed  formulas,  and  a 
set  of  rules  of  inference  (transformation  rules)  that,  given  a  certain 
sequence  of  well-formed  formulas,  permits  the  construction  of  another 
well-formed  formula.  The  symbols  chosen  vary  from  language  to 
language,  but  typically  they  contain  both  logical  constants  and  non- 
logical  vocabulary,  e.g.,  in  the  language  of  the  propositional  calculus  the 
logical  constants  are  truth-functional  connectives  and  the  non-logical 
vocabulary  consists  solely  of  sentence  letters,  in  the  predicate  calculus, 
variable,  predicates  and  quantifiers  are  needed.  The  formation  rules  will 
naturally  reflect  the  chosen  vocabulary.  The  rules  of  inference  are  to  be 
thought  of  as  governing  only  the  manipulation  of  symbols, 
independently  of  any  interpretation  they  may  have.  Although  formal 
languages  do  not  require  at  any  state  the  notion  of  an  interpretation,  they 
are  nevertheless  constructed  with  interpretations  in  mind,  and  rules  of 
inference  that  do  not  preserve  truth,  although  not  formally 
unsatisfactory,  are  of  no  interest. 

The  Fidelity 

ISG  Glossary 

Formalism 

The  practice  or  the  doctrine  of  strict  adherence  to  prescribed  or  external 
forms. 

Formalism 

Constraint  of  form  over  content. 

Formalisms 

Examples  are  UML,  CML,  SysML,  IDEFO,  BOM,  BOM++,  Conceptual 
Graphs,  Mind  Maps,  and  BPMN. 

Text 

Formality 

Amount  of  constraints  imposed  on  the  form. 

Formality 

Compliance  with  formal  or  conventional  rules. 

Text 

Formality 

Formality  is  compliance  with  formal  or  conventional  rules. 

Text 
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Generality 

Applicability  to  a  wide  class  of  instances. 

Glyph 

Responsible  for  holding  the  image  of  conceptual  model,  which  can  be 
used  to  visually  represent  a  conceptual  model  in  a  tool  palette  or  a  web 
repository.  From:  1.  A  structured  mark  or  symbol,  rare. 

Text,  OED 

Implementation 

Dependencies 

Constraints  occurring  at  time  of  creation  determined  during  the 
development  of  the  conceptual  model  and  manifest  at  the  time  of 
implementation  or  execution  of  the  conceptual  model,  such  as  may  result 
from  peculiarities  of  domain  ontologies,  representational  schema  or  any 
other  new  concept  introduced  by  the  process  during  the  implementation 
of  the  conceptual  model. 

Incentive 

Incentive  system:  “A  method  of  organizing  production  that  uses  a 
market-like  mechanism  inside  the  firm.” 

CFA  Institute 

Incentive 

Any  factor  (financial  or  non-financial)  that  provides  a  motive  for  a 
particular  course  of  action,  or  counts  as  a  reason  for  preferring  one 
choice  to  the  alternatives. 

Wikipedia 

Informal 

Conceptual  Model 

A  conceptual  model  with  the  following  attributers  or  consequences  of 

informality: 

-  Written  using  natural  language  and  contains  assumptions  made  during 
its  construction. 

-  Plays  fundamental  role  during  the  period  of  activity  when  the  modeler 
conceives,  programs,  debugs,  and  test  models. 

-  Helps  users  and  colleagues  comprehend  basic  outline  of  the  model 
from  their  perspective  on  how  the  real  world  operates. 

Jake  Borah 
Tutorial 

Information 

Details  the  capabilities  of  a  Behaviour,  Actor,  Event,  or  Control. 

Text 

Inheritance 

The  object-oriented  concept  where  a  child  class  also  has  the  features 
(attributes  and  methods)  of  its  parent  class;  one  of  the  types  of 
relationships  between  objects  in  the  data  model. 

SEDRIS 

Glossary 

Instantiation 

To  represent  an  abstraction  by  a  concrete  instance. 

The  Fidelity 

ISG  Glossary 

Interactions 

Transactions  among  entities  wherein  information  exchange  occurs  or 
causal  influence  is  manifest. 

Interoperability 

The  capability  of  two  or  more  simulation  components  to  operate 
together  concurrently  or  in  sequence  guaranteed  by  the  synchronized 
exchange  of  syntactic  and  semantically  consistent  data  signals/ 
messages. 

Investment 

The  process  of  adding  to  stocks  of  real  productive  assets.  This  may 
mean  acquiring  fixed  assets,  such  as  buildings,  plan,  or  equipment, 
or  adding  to  stocks  and  work  in  progress. 

Investment 

Incurring  costs  in  the  present  -  for  the  right  to  receive  future  benefits  / 
with  the  expectation  of  achieving  an  increased  benefit  in  the  future. 
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DEFINITION  or  COMMENT 

REFERENCE 

Investment 

The  process  of  expending  money  by  a/an  organization/individual/ 
department/entity/project  that  result  in  an  increase  of  assets. 

Investment 

Costs  that  result  in  the  acquisition  of,  or  addition  to,  end  items.  Such 
costs  benefit  future  periods  and  generally  are  of  a  long-term  character. 
Costs  budgeted  in  the  procurement  and  Military  Construction 
appropriations  are  considered  investment  costs.  Costs  budgeted  in  the 
Research,  Development,  Test  and  Evaluation  appropriation  can  be 
considered  investment  costs  or  expenses,  depending  on  the 
circumstances. 

Glossary  of 
Defense 
Acquisition 
Acronyms  & 
Terms,  Defense 
Acquisition 
University  Press 

Knowledge 

1)  The  rules,  environment,  etc.,  that  form  the  structure  humans  use  to 
process  and  relate  to  information,  or  the  information  a  computer  system 
must  have  to  behave  in  an  apparently  intelligent  manner.  2)  The  sum  or 
range  of  what  has  been  perceived  discovered  or  learned. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Legacy  Simulation/ 
Simulator 

Existing  simulation  asset  whose  initial  costs  are  already  incurred  and 
which  may  be  in  use  and  therefore  may  have  stakeholder  commitments 
for  continued  investment  and  use. 

M&S  Asset 

An  asset  or  assets  used  in  the  science,  practice,  development,  or  use  of 
M&S. 

M&S  Community 
(M&S  Community - 
of-Practice) 

The  ensemble  of  practitioners  comprising  the  population  of  individuals 
and  organizations  with  significant  interests  and  commitments  to 
modeling  and  simulation  disciplines,  practices,  assets  and  uses. 

M&S  Conceptual 
Model 

Conceptual  Model  intended  for  realizing  a  simulation  capability. 

Text 

M&S  Investment 

The  process  of  investing  (as  defined)  in  or  for  M&S  (as  defined)  assets 
(as  defined)  by  a/an  organization/individual/department/entity/project. 

M&S  Resources 

A  source  of  relevant  supply  -  in  the  case  of  M&S,  resources  normally 
include:  models,  simulations,  databases,  scenarios,  threat  libraries,  V&V 
histories,  accreditation  pedigrees,  environmental  representations, 
architectures,  and  interfaces;  but  they  may  also  include:  interfaces, 
simulation  federations,  games,  plans  and  policies,  personnel,  facilities 
and  equipment,  information  sources,  behaviors,  system  information  and 
documentation,  organizational  knowledge,  procedural  knowledge, 
operational  knowledge,  mappings  and  translations,  conceptual  models, 
transaction  protocols,  software  components,  execution  outputs,  and 
analysis  results  and  reports. 

Machine 

Readability 

Ability  of  information  to  be  perceived  by  a  machine  or  automaton  and 
subsequently  be  operated  upon  by  that  device. 

Market 

“The  means  through  which  buyers  and  sellers  are  brought  together  to  aid 
in  the  transfer  of  goods  and/or  services.” 

CFA  Institute 
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Market 

“Any  place  where  the  sellers  of  a  particular  good  or  service  can  meet 
with  the  buyers  of  that  goods  and  service  where  there  is  a  potential  for 
a  transaction  to  take  place.” 

http://economic 
s. about.com/cs/ 
economicsgloss 
ary/g/market.ht 
m 

Market 

“A  market  exists  whenever  potential  sellers  of  a  good  or  service  are 
brought  into  contact  with  potential  sellers  and  a  means  of  exchange  is 
available.” 

Graham 

Bannock 

Market 

In  general,  a  market  is  defined  as  the  group  of  individuals/organizations/ 
entities  that  has  the  need  for,  and  can  afford  a  product/service. 

Marketing 

definition 

Mathematical 

Model 

1)  Any  system  of  assumptions,  definitions  and  equations  that  represents 
particular  physical  phenomena.  See  model,  simulation,  conceptual 
model,  software  model.  2)  A  document  describing  the  assumptions, 
definitions  and  equations  that  represent  particular  physical  phenomena 
to  be  simulated  for  a  specific  application. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Measurement 

The  dimensional  or  quantitative  assignment  of  that  which  is  being 
assessed  (e.g.,  five  inches  long).  A  set  of  operations  having  the  object 
of  determining  a  value  of  a  measure. 

Practical 

Software 
Measurement, 
McGarry  et  all, 
2002 

Meta  Data 

Data  on  a  process,  event,  or  system  that  is  fundamentally  abstract  in 
nature.  A  set  of  “data  about  data”  that  characterizes  the  referent  in  a 
more  theoretical  manner  than  first  order  descriptors. 

Meta  Data 

Information  describing  the  characteristics  of  data;  data  or  information 
about  meaning  of  the  data;  descriptive  information  about  an 
organization’s  data,  data  activities,  systems,  and  holdings. 

DoD,  “Data 

Administration 

Procedures”, 

DoD  8320. 1-M, 
SEDRIS 

Glossary  29  Jun 
1998 

Meta-Knowledge 

Knowledge  about  knowledge;  knowledge  about  the  use  and  control  of 
domain  knowledge  in  an  expert  or  knowledge-based  system  or 
knowledge  about  how  the  system  operates  or  reasons;  wisdom. 

The  Fidelity 

ISG  Glossary 

Meta-Model 

“. . .  a  specification  model  for  a  class  of  systems  under  study,  where  each 
system  under  study  in  the  class  is  itself  a  valid  model  expressed  in  a 
certain  modeling  language.”  “. . .  a  meta-model  is  a  model  of  a  modeling 
language.” 

Dragan  Gasevic 

Meta-Model 

A  model  of  a  model.  Meta-models  are  abstractions  of  the  M&S  being 
developed  which  use  functional  decomposition  to  show  relationships, 
paths  of  data  and  algorithms,  ordering,  and  interactions  between  model 
components  and  sub-components.  Meta-models  allow  the  software 
engineers  who  are  developing  the  model  to  abstract  details  to  a  level  that 
subject-matter  experts  can  validate. 

The  Fidelity 

ISG  Glossary 
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REFERENCE 

Metric(s) 

Describe  a  system  of  measurement  that  includes:  the  item  or  object 
being  measured;  units  to  be  measured,  also  referred  to  as  “standard 
units”;  and  the  value  of  a  unit  as  compared  to  other  units  of  reference. 

(The  Metrics  of  Science  and  Technology,  Geisler,  2000). 

The  Metrics  of 
Science  and 
Technology, 
Geisler,  2000 

Military  Domain 

Domain  or  range  of  interest  of  entities  and  phenomenology  of  interest  to 
military  organizations  or  personnel. 

Military  Domain 
Experts 

Individuals  having  expert  or  specialized  knowledge  of  one  or  another 
military  domain. 

Military  M&S 
Conceptual  Model 

An  M&S  Conceptual  Model  within  the  military  domain. 

Text 

Military  Mission 
Space 

Mission  space  relating  to  military  entities  or  functions.  (See  Mission 
Space) 

Military  Modeling 

Modeling  conducted  in  support  of  military  organizations  or  functions  or 
representing  military  behaviours. 

Military  Scenario 

Scenario  of  interest  to  Military  operations  or  agents.  (See  Scenario) 

Mission  Space 

1)  The  [world]  in  which  a  particular  mission  is  performed.  2)  The 
environment  of  entities,  actions,  and  interactions  comprising  the  set  of 
interrelated  processes  used  by  individuals  and/or  organizations  to 
accomplish  assigned  tasks. 

Report  from 
the  Fidelity 
Implementation 
Study  Group, 
DoD,  “M&S 
Master  Plan”, 
DoD  5000-59-P 

Mission  Space 

Model 

A  model  based  primarily  upon  knowledge  of  the  real  world.  Such  a 
model,  if  based  entirely  upon  expert  opinion  of  the  real  world,  is  a 
preliminary  to  creating  a  mathematical  or  software  model.  A  mission 
space  model  of  an  object  should  describe  what  that  object  does,  at  some 
level  of  fidelity,  in  the  environment  in  which  the  mission  is  executed. 

See  model,  mathematical  model,  software  model,  mission  space. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Model 

1)  A  physical,  mathematical,  or  otherwise  logical  abstract  representation 
of  a  system,  entity,  phenomenon,  or  process  with  its  own  assumptions, 
limitations  and  approximations.  See  simulation,  conceptual  model, 
software  model,  mathematical  model.  2)  A  geometry  or  feature  assembly 
built  in  a  relative  coordinate  system  with  the  intent  to  multiply  instances 
of  the  assembly  at  one  or  more  world  coordinate  positions.  3)  A  system 
that  stands  for  or  represents  another  typically  more  comprehensive 
system. 

DoD,  “M&S 
Master  Plan”, 
DoD  5000-59-P 

Model  (Noun) 

A  pattern  of  something  to  be  made. 

Jake  Borah 
Tutorial 

Model  (Noun) 

“. . .  a  simplified  view  of  reality.”  “. . .  A  clear  set  of  formal  statements 
that  describes  something  ...  for  a  specific  purpose  ...” 

Dragan  Gasevic 
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Model  (Noun) 

I.  Representation  of  structure,  b  .fig.  Something  that  accurately 
resembles  something  else;  a  person  or  thing  that  is  the  likeness  or 
‘image’  of  another;  esp.  in  little  model ,  a  thing  that  represents  on  a  small 
scale  the  structure  or  qualities  of  something  greater,  c.  An  archetypal 
image  or  pattern,  e.  A  simplified  or  idealized  description  or  conception 
of  a  particular  system,  situation,  or  process  (often  in  mathematical  terms: 
so  mathematical  model)  that  is  put  forward  as  a  basis  for  calculations, 
predictions,  or  further  investigation. 

OED 

Model  (Noun) 

A  simplified/abstracted  representation  of  a  part  of  reality  or  a  potential 
reality. 

Text 

Model  (Noun) 

A  physical,  mathematical,  or  otherwise  logical  representation  of  a 
referent  of  interest 

Text 

Model  (Verb) 

l.a.  trans.  To  present  as  in  a  model  or  outline;  to  portray  or  describe  in 
detail,  b.  [after  MODEL  n.  2 e.]  To  devise  a  (usu.  mathematical)  model 
of  (a  phenomenon,  system,  etc.). 

OED 

Model  (Verb) 

...  to  produce  a  representation  of  or  simulation  of  [something]. 

Jake  Borah 
Tutorial 

Model 

Identification 

Data  structure  that  can  accommodate  information  related  to  the 
identification  of  a  conceptual  model  such  as:  Name,  Type,  Version, 
Modification  Date,  Security  Classification,  Release  Restriction,  Purpose, 
Application  Domain,  Description,  and  Use  Limitation. 

Model  Kinds 

Types  or  alternative  classes  of  models.  Examples  are  dynamic,  static, 
state  machine,  structural,  behavioral,  agent,  object-based,  process-based, 
Meta  data,  entity  relation,  activity,  composition,  generalization, 
collaboration,  event  trace  and  sequence. 

Text 

Modeling 

. . .  representation  [v.]  of  a  system  for  the  purpose  of  studying  the  system. 

Banks,  Carson, 
and  Nelson 

Modeling 

. . .  cost  effective  use  of  something  in  place  of  something  else  for  some 
purpose. 

Ray  Rothenburg 

Modeling 

Application  of  a  standard,  rigorous,  structured  methodology  to  create 
and  validate  a  physical,  mathematical,  or  otherwise  logical 
representation  of  a  system,  entity,  phenomenon,  or  process. 

The  Fidelity 

ISG  Glossary 

Modeling  and 
Simulation  (M&S) 

The  use  of  models,  including  emulators,  prototypes,  simulators,  and 
stimulators,  either  statically  or  over  time,  to  develop  data  as  a  basis  for 
making  managerial  or  technical  decisions.  The  terms  “modeling”  and 
“simulation”  are  often  (though  imprecisely)  used  interchangeably. 

MSETT 
NAWC-TSD 
Glossary;  DoD 
M&S  Glossary, 
DoD  5000.59-M 

Modeling  and 
Simulation  (M&S) 

The  use  of  models,  including  emulators,  prototypes,  simulators,  and 
stimulators,  either  statically  or  over  time,  to  develop  data  as  a  basis  for 
making  managerial  or  technical  decisions.  The  terms  “modeling”  and 
“simulation”  are  often  used  interchangeably. 

The  Fidelity 

ISG  Glossary 
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Need 

3. a.  Necessity  arising  from  the  facts  or  circumstance  of  the  case;  10.  A  A 
condition  marked  by  the  lack  or  want  of  some  necessary  thing,  or 
requiring  some  extraneous  aid  or  addition. 

OED 

Need 

A  ‘want’  or  ‘need’  is  related  to  the  state  of  expectation  or  intention  of 
one  or  another  of  the  stakeholders.  Individually  or  collectively, 
stakeholders  may  have  anticipatory  preferences  for  that  which  is 
produced  as  the  conceptual  model  proper  based  on  their  intended  use  for 
it  in  context  of  their  role  within  the  enterprise.  Wants  and  needs  in  this 
view  are  desiderata. 

Text 

Notation 

A  system  of  characters,  symbols,  or  abbreviated  expressions  used  in  an 
art  or  science  or  in  mathematics  or  logic  to  express  technical  facts  or 
quantities. 

Notation 

Set  of  names,  symbols,  or  other  semiotic  devices  together  with  syntactic 
rules  for  associated  the  elements  of  the  notation  into  meaningful 
statements. 

Notational  Schema 

Schema  (see  below)  manifest  as  notational  symbology. 

Object 

A  fundamental  element  of  a  conceptual  representation  for  a  federate  that 
reflects  the  “real  world”  at  levels  of  abstraction  and  resolution  appropriate 
for  federate  interoperability.  For  any  given  value  of  time  the  state  of  an 
object  is  defined  as  the  enumeration  of  all  its  attribute  values. 

The  Fidelity 

ISG  Glossary 

Object  Model 

A  specification  of  the  objects  intrinsic  to  a  given  system,  including  a 
description  of  the  object  characteristics,  or  attributes,  and  a  description 
of  the  static  and  dynamic  relationships  that  exist  between  objects. 

The  Fidelity 

ISG  Glossary 

Ontology 

Ontologies  are  formalized  vocabularies  of  terms,  often  covering  a 
specific  domain  and  shared  by  a  community  of  users.  They  specify  the 
definitions  of  terms  by  describing  their  relationships  with  other  terms  in 
the  ontology. 

Lee  Lacey 

Ontology 

‘An’  ontology  is  a  specification  of  a  conceptualization.  Practically, 

“A  representation  vocabulary  often  specialized  to  some  domain”. 

“...  the  body  of  knowledge  describing  the  domain  using  the  representation 
vocabulary”  “...  an  explicit  representation  of  a  shared  understanding  of 
the  important  concepts  in  some  domain  of  interest”. 

OED;  Dragan 
Gasevic 

Ontology 

Combination  of  objects  and  processes  of  interest. 

Text 

Ontology 

An  explicit  formal  conceptualisation  of  a  shared  understanding  of  the 
domain  of  interest  including  the  vocabulary  of  terms,  semantics  as  well 
as  their  pragmatics. 

Text 

Ontology 

In  short,  ‘ontology’  asks  the  rhetorical  question:  What  is  there?  In  the 
present  context,  more  specific  formulations  might  be:  What  do  we  care 
about,  or  alternatively,  what  is  it  necessary  to  represent  in  a  model  or 
simulation  in  order  for  the  resulting  product  to  serve  its  intended  use? 
Given  this  knowledge,  the  next  question  that  must  be  addressed  is:  How 
can  one  select,  and  document  the  contents  of  such  a  representation? 

Text 
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DEFINITION  or  COMMENT 

REFERENCE 

Ontology  (Formal) 

Ontologies  may  be  classified  depending  upon  both  their  formality  and 
complexity  as  a  continuum  as  belong  to  the  following  major  categories: 
Highly  Informal,  Semi  Formal,  and  Rigorously  Formal.  Formal 
ontologies  are  considered  to  be:  the  systematic  formal,  axiomatic 

development  of  the  logic  of  all  forms  and  modes  of  being.  It  studies  the 
formal  properties  and  classification  of  the  entities  of  the  world  (physical 
objects,  events,  etc.),  and  of  the  categories  that  model  the  world 
(concepts,  property,  etc.)” 

Asuncion 

Gomez  Perez 

Pattern(s) 

.  1)  a.  The  original  proposed  imitation;  the  archetype;  that  which  is  to  be 
copied;  an  exemplar’  (J.);  an  example  or  model  deserving  imitation;  an 
example  or  model  of  a  particular  excellence.  2)  a.  Anything  fashioned, 
shaped,  or  designed  to  serve  as  a  model  from  which  something  is  to  be 
made;  a  model,  design,  plan,  or  outline,  [therefore  a  kind  of  a  model].  6) 
An  example,  an  instance;  esp.  a  typical,  model,  or  representative 
instance,  a  signal  example,  c  .fig.  An  arrangement  or  order  of  things  or 
activity  in  abstract  senses;  order  or  form  discernible  in  things,  actions, 
ideas,  situations,  etc. 

OED 

Policy 

A  deliberate  plan  of  action  to  guide  decisions  and  achieve  rational 
outcomes. 

Wikipedia 

Precision 

1)  The  quality  or  state  of  being  clearly  depicted,  definite,  measured  or 
calculated.  2)  A  quality  associated  with  the  spread  of  data  obtained  in 
repetitions  of  an  experiment  as  measured  by  variance;  the  lower  the 
variance,  the  higher  the  precision.  3)  A  measure  of  how  meticulously  or 
rigorously  computational  processes  are  described  or  performed  by  a 
model  or  simulation.  See  resolution,  sensitivity. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Predicate 

1)  Logic.  That  which  is  predicated  or  said  of  the  subject  in  a  proposition. 

2)  Gram  c.  A  quality,  an  attribute. 

OED 

Primitives 

Elemental  components  from  which  higher-order  composites  may  be 
composed.  Commonly  applied  to  conceptual  model  constructs. 

Examples  are  entity,  object,  signal,  time,  event,  attribute,  message,  state. 

Text 

Process 

1)  Something  that  affects  entities  (e.g.,  attrition,  communications,  and 
movement).  Processes  have  a  level  of  detail  by  which  they  are  described. 

2)  A  system  of  operations  in  producing  something.  3)  A  series  of 
actions,  changes,  or  functions  that  achieve  an  end  or  result. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Process 

Consistency, 
Commonality  and 
Tailorability 

Processes  comprising  the  conceptual  model  best-practice  must  be 
appropriate  for  execution  in  a  NATO-diverse  constituency.  Best-practice 
process  elements  must  be  sufficiently  consistent  that  participation  in 
conceptual  modeling  can  be  extended  across  any  sub-set  of  the  NATO 
M&S  community. 
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DEFINITION  or  COMMENT 

REFERENCE 

Process 

Consistency, 
Commonality  and 
Tailorability 
(cont’d) 

Practice  commonality  must  have  a  similar  domain  in  order  that  suitable 
common  ground  exist  from  which  NATO  M&S  constituents  may  fully 
appreciate  both  how  conceptual  models  were  achieved  and  what  their 
contents  are  once  produced.  Conceptual  modeling  processes  and 
products  must,  nevertheless,  be  sufficiently  tailorable  so  that  they  can 
be  socialized  by  any  particular  sub-set  of  the  enterprise  to  which  they 
will  particularly  pertain  -  and  they  must  be  sufficiently  tailorable  as  to 
admit  the  specific  referent  subject  matter,  conceptual  constructs,  and 
representational  schemas  as  may  be  elected  by  one  or  another  sub-set 
of  the  stakeholder  community. 

Process  Guidance 

Prescriptive  guidance  specifying  the  effort  or  activity  necessary  and 
sufficient  to  create  a  desired  work-product  resulting  from  a 
developmental  activity. 

Process  Model 

A  model  of  the  processes  performed  by  a  system  (e.g.,  a  model  that 
represents  the  software  development  process  as  a  sequence  of  phases). 

See  structural  model. 

The  Fidelity 

ISG  Glossary 

Producer 

This  is  a  person  or  organization  that  will  endeavour  to  satisfy  the 
sponsor’s  need. 

Text 

Producer 

(Knowledge 

Engineer) 

1)  Understanding  of  operational  issues  and  mission  context. 

2)  Translation  of  operational  issues  and  mission  context  into  a 
conceptual  model.  3)  Unambiguous  communication  with  SMEs  and 
implementers. 

Text 

Producer 
(M&S  PM) 

1)  Effective  use  of  allocated  resources  (e.g.,  ensuring  reuse  when 
appropriate).  2)  Unambiguous  communication  with  customer. 

Text 

Producer 
(M&S  SME) 

Military  SME 

1)  Understanding  of  operational  issues  and  mission  context. 

2)  Translation  of  operational  issues  and  mission  context  into  a 
conceptual  model.  3)  Unambiguous  communication  with  SMEs  and 
implementers. 

Producer 
(M&S  SME) 

1)  Understanding  of  operational  issues  and  mission  context.  2)  Provide 
technical  and  military  know-how  at  appropriate  level  of  detail. 

Text 

Product 

Consistency 

Conceptual  model  product  consistency  must  be  sufficient  that  the 
library  of  conceptual  models  deployed  and  used  within  the  NATO  M&S 
enterprise  are  at  least  evidently  interpretable  among  stakeholders,  and 
preferably  interoperable  (to  within  similarity  of  mission  space  referents) 
across  the  enterprise..  While  complete  interoperability  and  exhaustive 
re-usability  are  not  likely  to  occur  even  under  the  most  auspicious 
circumstances,  and  while  it  is  certain  that  no  degree  of  product  ‘best- 
practice’  results  could  guarantee  such  consistency,  any  element  of  the 
prescribed  practice  that  can  be  established  with  a  view  to  improving 
product  consistency  should  be  adopted. 

Product  Guidance 

Prescriptive  guidance  specifying  the  nature  of  the  subject  work-product 
resulting  from  a  developmental  activity. 
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Product  Quality 

Conceptual  model  product  quality  across  the  enterprise  is  relevant  from 
two  complimentary  perspectives.  On  the  one  hand  consistent  quality  in 
fact  resulting  from  the  subject  guidance  is  directly  correlated  to  the 
value  of  the  return  on  investment  in  conceptual  modeling  itself  On  the 
other  hand,  sufficient  and  auditably  documented  product  quality  across 
conceptual  models  will  influence  greatly  both  the  likelihood  of  use  of 
the  conceptual  modeling  best-practice  guidance  and  the  re-use  sharing, 
and  recovery  of  utility  of  the  pursuant  models  themselves. 

Project  Manager 

Role  title  relating  to  responsible  agent  leading  a  project  or  program  of 
activity. 

Properties 

Attributes,  characteristics  of  a  thing  or  process. 

Purpose(s) 

1)  a.  That  which  one  sets  before  oneself  as  a  thing  to  be  done  or  attained; 
the  object  which  one  has  in  view.  2)  a.  Without  a  or  pi.  The  action  or 
fact  of  intending  or  meaning  to  do  something;  intention,  resolution, 
determination.  3)  The  object  for  which  anything  is  done  or  made,  or  for 
which  it  exists;  the  result  or  effect  intended  or  sought;  end,  aim. 

OED 

Quality 

A  totality  of  features  and  characteristics  of  a  conceptual  model  that  bear 
on  its  ability  to  satisfy  stated  or  implied  needs.  It  measures  how  “good” 
a  conceptual  model  might  be  for  various  purposes. 

Text 

Quality 

Measures  how  “good”  a  conceptual  model  might  be  for  various 
purposes. 

Text 

Real-Time 

In  modelling  and  simulation,  simulated  time  advances  at  the  same  rate 
as  actual  time  (e.g.,  running  the  simulation  for  one  second  results  in  the 
model  advancing  time  by  one  second).  See  fast  time,  slow  time. 

The  Fidelity 

ISG  Glossary 

Real-World 

The  set  of  real  or  hypothetical  causes  and  effects  that  simulation 
technology  attempts  to  replicate.  See  real  battlefield.  The  real  world 
defines  one  standard  against  which  fidelity  is  measured  that  includes 
both  imagined  reality  and  material  reality  in  order  to  accommodate 
assessment  of  simulation  fidelity  when  future  concepts  and  systems  are 
involved.  See  fidelity,  imagined  reality,  material  reality,  perceived  truth. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Reference 

A  pointer  to  additional  sources  of  information  such  as  locations  in  XML 
documents  and  references  to  ontologies  (both  domain  and  middle  level) 
which  are  used  by  the  conceptual  model. 

Referent 

That  part  of  the  mission-space  being  represented  in  the  simulation  - 
also  denoted  the  ‘simuland’. 

Referent 

a.  That  to  which  something  has  reference;  spec,  that  which  is  referred  to 
by  a  word  or  expression.  Also  in  Comb,  (appositively),  as  referent- 
object. 

OED 

Referent 

A  set  of  Active  or  existing  systems,  entities,  phenomena,  or  processes 
subjected  to  modeling  and  simulation  which  a  user  may  want  to  consider 
in  the  context  of  their  own  objects  or  interests. 

Text 
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REFERENCE 

Referent 

1)  A  codified  body  of  knowledge  about  a  thing  being  simulated. 

2)  Something  referenced  or  singled  out  for  attention,  a  designated  object, 
real  or  imaginary  or  any  class  of  such  objects. 

Report  from 
the  Fidelity 
Implementation 
Study  Group, 
Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Relation 

3)  a.  That  feature  or  attribute  of  things  which  is  involved  in  considering 
them  in  comparison  or  contrast  with  each  other;  the  particular  way  in 
which  one  thin  is  thought  of  in  connection  with  another;  any  connection, 
correspondence,  or  association,  which  can  be  conceived  as  naturally 
existing  between  things. 

OED 

Relationship 

The  state  of  being  related;  a  condition  or  character  based  upon  this. 

Repository 

A  place  where  data  or  specimens  are  stored  and  maintained  for  future 
retrieval. 

Wikipedia 

Representation 

2)  a.  n  An  image,  likeness,  or  reproduction  in  some  manner  of  a  thing, 
d.  The  fact  of  expressing  or  denoting  by  means  of  a  figure  or  symbol; 
symbolic  action  or  exhibition.  6)  a.  v  The  action  of  presenting  to  the 
mind  or  imagination;  an  image  thus  presented;  a  clearly-conceived  idea 
or  concept. 

OED 

Representation 

1)  Something  that  stands  in  place  of  or  is  chosen  to  substitute  for 
something  else,  e.g.,  representation  of  constituencies  in  government, 
linguistic  representation  of  an  event.  2)  Something  that  describes  as  an 
embodiment  of  a  specified  quality.  3)  The  homomorphism  of  a  group  of 
abstract  symbols  into  a  group  of  more  familiar  objects.  4)  A  model  or 
simulation. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995,  Report 
from  the 

Fidelity 

Implementation 
Study  Group 

Representational 

Polymorphism 

Multiple  representations  of  the  same  data  to  serve  the  needs  of  different 
users. 

SEDRIS 

Glossary 

Requirement 

3)  That  which  is  required  or  needed;  a  want,  need.  b.  that  which  is  called 
for  or  demanded;  a  condition  which  must  be  complied  with. 

OED 

Requirement 

A  ‘requirement’  is  related  to  the  necessary  and  sufficient  attributes  of  the 
conceptual  model  as  determined  appropriate  for  the  enterprise  at  large. 
Requirements  both  prescribe  and  proscribe  the  characteristics  of  the 
conceptual  model  which,  if  present,  guarantee  the  model  to  be  adequate 
for  its  several  intended  uses. 

Text 
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Requirement 

(cont’d) 

As  such,  requirements  must  be  monolithic  within  the  enterprise  and 
must  manifest  the  potentially  disparate  stakeholders’  wants  and  needs  in 
positive-definite,  observable  form. 

Text 

Resolution 

1)  The  degree  of  detail  used  to  represent  aspects  of  the  real  world  or  a 
specified  standard  or  referent  by  a  model  or  simulation.  2)  Separation  or 
reduction  of  something  into  its  constituent  parts;  granularity. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Reusability 

Able  to  be  used  again;  suitable  for  second  or  further  usage. 

Reuse 

For  an  asset  to  be  used  again  subsequent  to  its  initial  intended  use. 

Risk 

Possibility  that  actual  outcomes  will  vary  from  what  is  expected. 

Risk 

A  measure  of  the  inability  to  achieve  program  objectives  within  defined 
cost  and  schedule  constraints.  It  has  two  components:  the  probability  of 
failing  to  achieve  a  particular  outcome,  and  the  consequences  of  failing 
to  achieve  that  outcome. 

Glossary  of 
Defense 
Acquisition 
Acronyms  & 
Terms,  Defense 
Acquisition 
University  Press 

Risk 

“The  chance  of  things  not  turning  out  as  expected.  Risk  taking  lies  at  the 
heart  of  capitalism  and  is  responsible  for  a  large  part  of  the  growth  of  an 
economy.  In  general,  economists  assume  that  people  are  willing  to  be 
exposed  to  increased  risks  only  if,  on  average,  they  can  expect  to  earn 
higher  returns  than  if  they  had  less  exposure  to  risk.” 

http://www.eco 

nomist.com/rese 

arch/economics 

Role 

The  named  designation  of  a  relationship  that  may  be  assigned-to  or 
assumed-by  an  individual  or  organization  with  respect  to  some  function 
or  organizational  entity.  Role  is  intended  to  imply  requisite  authority  and 
concomitant  responsibility  to  execute  the  associated  functions  or  to  act 
successfully  in  relation  to  the  designated  organizational  entity. 

Webster.. .”a 
part  or  character 
assumed  by 
anyone.” 

Role  (Functional) 
Authority 

Those  functions  (including  decisions)  that  the  individual  person  or 
organization  assigned  to  a  role  class  or  instance  may  perform.  . . .  what 
the  role  holder  may  do. 

Role  (Functional) 
Responsibility 

Those  functions  that  must  be  performed  by  the  person  or  organization 
assigned  to  any  particular  role  class  or  instance.  Performance  of 
functional  responsibilities  is  a  necessary  condition  of  satisfactory  role- 
position  execution.  . . .  what  the  role  holder  must  do. 

Scale 

A  specified,  graduated  reference  used  to  measure  the  value  of  an  item  to 
a  decision-maker  or  user. 

Scenario 

2)  A  sketch,  outline,  or  description  of  an  imagined  situation  or  sequence 
of  events;  esp.  (a)  a  synopsis  of  the  development  of  a  hypothetical  future 
world  war,  and  hence  an  outline  of  any  possible  sequence  of  future 
events;  (b)  an  outline  of  an  intended  course  of  action;  (c)  a  scientific 
model  or  description  intended  to  account  for  observable  facts. 
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REFERENCE 

Scenario  (cont’d) 

Hence,  in  weakened  series  (not  easily  distinguishable  from  sense  la 
transf.  and  fig.):  a  circumstance,  situation,  scene,  sequence  of  events,  etc. 

OED 

Schema 

1)  a.  Philos.  In  Kant:  Any  one  of  certain  forms  or  rules  of  the 
‘productive’  imagination’  through  which  the  understanding  is  able  to 
apply  its  6  categories’  to  the  manifold  of  sense-perception  in  the  process 
of  realizing  knowledge  or  experience...  (e.g.,  A  rule  that  organizes 
perceptions  into  a  unitary  whole.)  b.  Neurol  and  Psychol.  An  automatic, 
unconscious  coding  or  organization  of  incoming  physiological  or 
psychological  stimuli,  giving  rise  to  a  particular  response  or  effect. 

OED 

Scope 

The  range,  breadth,  or  degree  of  extension  of  the  universe  of  discourse. 

Semantic(s) 

2)  a.  Relating  to  signification  or  meaning. 

OED 

Semantics 

The  components  of  a  rule  or  lexical  entry  that  define  the  meaning  of  a 
morpheme,  word,  phrase,  or  sentence. 

Steven  Pinker 

Semantics 

1)  The  implied  meaning  of  data  to  define  what  entities  mean  with 
respect  to  their  roles  in  a  system.  2)  The  study  of  relationships  between 
signs  and  symbols  and  what  they  represent  to  their  interpreters. 

SEDRIS 
Glossary,  29 

Jun  1998, 
Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Simplification 

Analytical  technique  in  which  unimportant  details  are  removed  in  order 
to  define  simpler  relationships. 

Jake  Borah 
Tutorial 

Simuland 

The  system  being  simulated  by  a  simulation.  See  referent,  model,  and 
simulation. 

The  Fidelity 

ISG  Glossary 

Simulation 

The  imitative  representation  of  the  functioning  of  one  system  or  process 
by  means  of  the  functioning  of  another”. 

Simulation 

The  implementation  of  a  model  over  time. 

Text 

Simulation 

1)  A  method,  software  framework  or  system  for  implementing  one  or 
more  models  in  the  proper  order  to  determine  how  key  properties  of  the 
original  may  change  over  time.  See  model,  representation.  2)  An 
unobtrusive  scientific  method  of  inquiry  involving  experiments  with  a 
model  rather  than  with  the  portion  of  reality  this  model  represents. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Simulation 
Conceptual  Model 

Conceptual  model  of  or  for  a  simulation. 

Simulation 

Engineering 

Sub-discipline  of  engineering  where  models  and  simulations  are  the 
systems  of  interest. 

Simulation 
Executable  Model 

The  model  as  it  is  actually  implemented  and  exercised  in  the  simulation. 
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Simulation  Process 

The  imitative  representation  of  the  actions  of  platform(s),  munition(s), 
and  life  form(s)  by  computer  program(s)  in  accordance  with  a 
mathematical  model  and  the  generation  of  associated  battlefield  entities 
that  may  be  fully  automated  or  partially  automated. 

The  Fidelity 

ISG  Glossary 

Simulation  Space 

The  simulation  artefact  wherein  simulation  mission  space  representation 
is  manifest. 

Sponsor 

Person  or  organization  that  sees  a  need  for  modeling  and  simulation  in 
the  solving  of  a  problem  such  as  specifying  an  operation  requirement  or 
analyzing  a  capability. 

Text 

Sponsor 

Responsibility 

Responsibilities  of  a  sponsor  role  agent  include:  1)  Analysis  of  combat 
outcome,  system  performance,  system  alternative  trade-offs,  etc. 

2)  Cost-effective  training.  3)  Credibility  of  analysis  results.  4)  Making 
sure  the  Conceptual  Model  represents  necessary  and  sufficient  relevant 
information  about  operational  issues  and  mission  context  of  interest 
(correct  scope).  5)  Decision-making  based  on  analysis  products 
(introducing  a  new  tactic,  procuring  a  new  system,  etc.).  6)  Cost  of 
modeling  and  simulation. 

Stakeholder 

Community 

Conceptual  modeling  will  be  conducted  and  its  value  recovered  in  a 
community  or  practice  commensurate  with  the  scope  and  diversity  of  the 
enterprise  participants.  Concepts  invoked  to  develop,  understand,  share, 
and  reuse  conceptual  model  artifacts  with  confidence,  and  with 
reasonable  expectation  of  accruing  the  benefits  of  shared  investment 
require  that  all  stakeholder  roles  be  carefully  defined  and  be  appreciated 
as  pertaining  across  the  enterprise  scope. 

Stakeholder(s) 

People  or  organizational  persons  likely  to  be  affected  by  a  process  or 
product. 

Standard 

1)  An  accepted  measure  of  comparison  for  quantitative  or  qualitative 
value;  a  criterion.  2)  Proposition  of  a  norm  or  general  pattern  to  be 
followed  when  constructing,  operating  or  testing  a  (technical)  device. 

A  standard  contains  a  set  of  reference  criteria  for  functional,  structural, 
performance  or  quality  aspects  of  a  device  or  for  any  combination  of 
these. 

Houghton 

Mifflin  Co., 
Webster’s  II, 

New  College 
Dictionary, 

1995 

Standard(s) 

10)  a.  (Originally  fig  from  9.)  An  authoritative  or  recognized  exemplar 
of  correctness,  perfection,  or  some  definite  degree  of  any  quality, 
b.  A  rule,  principle,  or  means  of  judgement  or  estimation;  a  criterion, 
measure.  12)  a.  A  definite  degree  of  any  quality,  viewed  as  a  prescribed 
object  of  endeavour  or  as  the  measure  of  what  is  adequate  for  some 
purpose. 

OED 

Stimulation 

The  use  of  simulations  to  provide  an  external  stimulus  to  a  system  or 
sub-system  (e.g.,  using  a  simulation  representing  the  radar  return  from  a 
target  to  drive  (stimulate)  the  radar  of  a  missile  system  within  a  hardware/ 
software-in-the-loop  simulation). 

The  Fidelity 

ISG  Glossary 
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Subject-Matter 

Expert 

Individual  particularly  well-informed  or  adept  in  one  or  another  subject 
matter  domain. 

Syntactic 

Expression 

Facilitates  enforcement  of  syntactic  precision  upon  statements  whose 
semantic-information  content  is  left  to  the  modeller  agent. 

Text 

Syntax 

The  component  of  grammar  that  arranges  words  into  phrases  and 
sentences. 

Steven  Pinker 

System  of  Interest 

Set  of  flctive  or  existing  systems,  entities,  phenomena,  or  processes 
subjected  to  modeling  and  simulation  representation  and  which  a  user 
of  the  system  wants  to  consider  in  the  context  of  their  own  needs, 
objectives  or  interests. 

Tailorable 

Attribute  of  an  entity  or  process  whereby  it  admits  to  being  changed 
specifically  in  order  to  make  it  more  suitably  relevant  or  purposefully  fit 
for  some  particular  intended  purpose  or  use. 

Task 

A  task  is  a  description  of  a  military  activity,  including  the  activity 
performer  and  the  activity  object(s).  It  may  be  decomposed  into  sub¬ 
tasks  (recursively  decomposable)  or  steps  (atomic). 

Traceability 

Every  requirement  statement  can  be  referred  to  a  corresponding  need, 
constraint  or  policy  statement. 

Traceability 

The  quality  of  being  traceable;  to  follow  the  course,  development, 
or  history  of.  Also  with  the  course,  etc.,  as  object,  fit. 

Traceability 

Left  to  conceptual  model  stakeholder  practitioner  with  respect  to 
selection,  modification  and  interpretation  of  notational  schemas. 

Text 

Unambiguity 

The  requirement  is  given  a  form  that  avoids  misinterpretation. 

Universe  of 
Stakeholders 

All  of  the  participants  with  an  abiding  interest  (types  or  individuals) 
relevant  to  a  specific  use  case  or  instance  of  investment  management. 

Use  Cases 

A  description  of  a  system’s  behavior  as  it  responds  to  a  request  that 
originates  from  outside  of  that  system.  The  use  case  technique  is  used  in 
software  and  systems  engineering  to  capture  the  functional  requirements 
of  a  system.  Use  cases  describe  the  interaction  between  a  primary  Actor 
(the  initiator  of  the  interaction)  and  the  system  itself,  represented  as  a 
sequence  of  simple  steps.  Actors  are  something  or  someone  which  exists 
outside  the  system  under  study,  and  that  take  part  in  a  sequence  of 
activities  in  a  dialogue  with  the  system  to  achieve  some  goal.  They  may 
be  end  users,  other  systems,  or  hardware  devices.  Each  use  case  is  a 
complete  series  of  events,  described  from  the  point  of  view  of  the  Actor. 

In  this  case  the  system  is  the  simulation  conceptual  model. 

http://en.wikipe 

dia.org/wiki/Us 

e_case 

User 

Role  specification  denoting  individual  or  organization  who  will  employ 
the  subject  (conceptual  model)  work-product  for  any  of  a  variety  of 
purposes  within  scope  of  the  M&S  enterprise. 

User-Needs 

See  User  and  Needs. 

Users’  View 

See  User  and  View. 
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Term 

DEFINITION  or  COMMENT 

REFERENCE 

Utility 

The  “utility”  of  something  is  one  factor  that  is  taken  into  consideration 
when  determining  things  of  “value.” 

Utility 

Economist-speak  for  a  good  thing;  a  measure  of  satisfaction.  Underlying 
most  economic  theory  is  the  assumption  that  people  do  things  because 
doing  so  gives  them  utility.  Individuals  strive  to  achieve  as  much  utility 
as  possible.  However,  the  more  they  have  the  less  difference  an 
additional  unit  of  utility  will  make  -  there  is  diminishing  marginal 
utility.  Utility  is  not  the  same  as  utilitarianism,  a  political  philosophy 
based  on  achieving  the  greatest  happiness  of  the  greatest  number. 

Utility 

The  (relative)  importance  of  items  in  a  class  to  an  agent. 

Choices:  An 
Introduction 
to  Decision 
Theory,  Resnik, 
1987 

Utility 

The  state  or  quality  of  being  useful  militarily  or  operationally.  Designed 
for  or  possessing  a  number  of  useful  or  practical  purposes  rather  than  a 
single,  specialized  one. 

Glossary  of 
Defense 
Acquisition 
Acronyms  & 
Terms,  Defense 
Acquisition 
University  Press 

Utility 

Utility  is  the  property  of  the  relative  satisfaction  gained  by  the  use  of  a 
system  expressed  in  terms  of  a  value  and  cost.  It  measures  the  kinds  of 
purposes  for  which  the  conceptual  model  might  provide  value. 

Text 

Utility 

Assesses  the  effectiveness  and  efficiency  of  the  conceptual  model  in 
solving  the  problem  statement. 

Text 

Utility  Function 

A  representation  of  a  consumer’s  preferences  that  maps  potential  and 
actual  items  and  outcomes  and  the  value  preferences  of  a  consumer  or 
decision-maker. 

Utility  Scales 

A  specified,  graduated  reference  used  to  measure  the  value  of  an  item  or 
process  to  a  decision-maker  or  user. 

V&V  Agents 

Role  title  for  those  responsible  for  managing  verification  and  validation 
within  an  M&S  enterprise  environment. 

V&V  Data 

Elements 

The  V&V  process  can  produce  an  enormous  amount  of  data.  These  data 
are  collected  under  a  label  called  V&V  Data  Elements  and  placed  in  the 
product  “conceptual  model  Meta  data”.  In  the  table  below  a  list  of  data 
items  is  presented  together  with  the  Process  Activities  where  that  data  is 
produced. 

Validation 

The  process  of  determining  the  degree  to  which  a  model  or  simulation  is 
an  accurate  representation  of  the  real  world,  or  some  other  meaningful 
referent,  from  the  perspective  of  the  intended  uses  of  the  model  or 
simulation. 
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Term 

DEFINITION  or  COMMENT 

REFERENCE 

Validation 

The  purpose  of  the  Validation  Process  is  to  provide  objective  evidence 
that  the  services  provided  by  a  system  entity  when  in  use  comply  with 
stakeholders’  requirements. 

Validation  of 
Conceptual  Model 

Process  of  validation  applied  to  subject  conceptual  model.  See  validation 
and  conceptual  model. 

Validity 

The  property  of  a  simulation  model  to  have,  within  a  specific 
experimental  frame,  a  behavior  which  is  indistinguishable  under  a  set  of 
validation  criteria  from  the  behavior  of  the  System  of  Interest. 

Validity 

Assesses  the  level  of  agreement  of  the  conceptual  model  behavioral 
representation  with  that  of  the  simuland. 

Text 

Validity 

1)  The  quality  of  being  inferred,  deduced  or  calculated  correctly  enough 
to  suit  a  specific  application.  2)  The  quality  of  maintained  data  that  is 
found  on  an  adequate  system  of  classification  (e.g.,  data  model)  and  is 
rigorous  enough  to  compel  acceptance  for  a  specific  use.  3)  The  logical 
truth  of  a  derivation  or  statement,  based  on  a  given  set  of  propositions. 

Report  from 
the  Fidelity 
Implementation 
Study  Group 

Value 

1.1. a.  That  amount  of  some  commodity,  medium  of  exchange,  etc., 
which  is  considered  to  be  an  equivalent  for  something  else.  (See  Cost) 

OED 

Verification 

The  purpose  of  the  Verification  Process  is  to  confirm  that  the  specified 
design  requirements  are  fulfilled  by  the  system  entity. 

Verification 

The  process  of  determining  that  a  model  or  simulation  implementation 
accurately  represents  the  developer’s  conceptual  description  and 
specification.  Verification  also  evaluates  the  extent  to  which  the  model 
or  simulation  has  been  developed  using  sound  and  established  software 
engineering  techniques. 

DoD,  “M&S 
Master  Plan”, 
DoD  5000-59-P 

View 

Instance  of  a  model  kind  with  selected  information. 

Views 

Examples  are  class  diagram,  activity  diagrams,  swim  lanes,  state 
diagram,  operational  view,  etc. 

Want 

2)  a.  Deficiency,  shortage  or  lack  (of  something,  desirable  or  necessary, 
esp  a  quality  or  attribute).  5)  a  A  condition  marked  by  the  lack  of  some 
necessary  thing,  or  requiring  some  extraneous  aid  or  addition;  need; 
also,  an  instance  of  this,  and  so  freq.  pi  (passing  into  the  quasi-  concr , 
sense’  requirement’. 

OED 

Want 

A  ‘want’  or  ‘need’  is  related  to  the  state  of  expectation  or  intention  of 
one  or  another  of  the  stakeholders.  Individually  or  collectively, 
stakeholders  may  have  anticipatory  preferences  for  that  which  is 
produced  as  the  conceptual  model  proper  based  on  their  intended  use  for 
it  in  context  of  their  role  within  the  enterprise.  Wants  and  needs  in  this 
view  are  desiderata. 

Text 
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Annex  K  -  BIBLIOGRAPHY 


The  literature  of  conceptual  modeling  is  hopelessly  large  and  diffuse.  This  follows  naturally  from  the  diversity 
of  the  significance  of  the  key  terms,  ‘model’  and  ‘concept’.  Topical  scope  of  references  ranges  from  the  entire 
philosophical  field  of  ontology  through  conceptualization  used  for  software,  and  most  recently  simulation. 
References  address,  primitive  ideas,  practices,  and  process,  tools,  and  concrete  results  over  a  range  of  referent 
domains  that  is  as  large  as  the  world  itself.  While  the  Task  Group  did  feel  the  need  to  anchor  its  deliberations 
in  firmly  in  the  academic  and  practical  literature  of  conceptual  modeling  and  to  provide  relevant  citations 
allowing  the  reader  to  connect  the  ‘web  of  belief  at  which  the  Task  Group  finally  arrived  with  their  own 
appreciation  of  the  intellectual  subject;  we  soon  realized  that  a  comprehensive  bibliographic  search  and 
analysis  would  itself  consume  the  entire  resources  of  the  study  effort.  Caught  between  the  Scylla  of  academic 
grounding  and  the  Chaybdis  of  finite  resources;  we  have  elected  to  cite  those  references  that  provided  us 
genuine  insight,  represented  most  evocatively  the  ‘world’  of  modeling  and  simulating  in  which  we  are 
embedded,  or  occasionally,  provided  background  so  influential  and  broadly  relevant  that  it  could  be  neglected 
only  at  the  risk  of  depriving  the  reader  of  one  or  another  of  those  canonical  hooks  upon  which  he  might 
anchor  his  own  evolving  interpretation  of  the  subject.  The  bibliographic  references  that  follow,  therefore, 
include  all  citations  invoked  by  footnotes  in  the  text  as  well  as  those  collateral  citations  that  seemed  most 
likely  to  support  the  reader’s  understanding  and  appreciation  of  the  subject  document.  We  regret  egregious 
omissions  that  will  be  apparent  to  any  well-informed  reader  and  plead  necessity  of  economy  as  our  only 
defence. 

[1]  About.com  Website;  Definition  of  Market;  http://economics.about.eom/cs/economiesglossary/g/market. 
htm. 
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